Wireshark 2 
Quick Start 
eq hfe [= 





By Charit Mishra 

















Wireshark 2 Quick Start 
Guide 


Copyright © 2018 Packt Publishing 


All rights reserved. No part of this book may be reproduced, stored in a retrieval system, 
or transmitted in any form or by any means, without the prior written permission of the 
publisher, except in the case of brief quotations embedded in critical articles or reviews. 


Every effort has been made in the preparation of this book to ensure the accuracy of the 
information presented. However, the information contained in this book is sold without 
warranty, either express or implied. Neither the author, nor Packt Publishing or its 
dealers and distributors, will be held liable for any damages caused or alleged to have 
been caused directly or indirectly by this book. 


Packt Publishing has endeavored to provide trademark information about all of the 
companies and products mentioned in this book by the appropriate use of capitals. 
However, Packt Publishing cannot guarantee the accuracy of this information. 


Commissioning Editor: Vijin Boricha 
Acquisition Editor: Reshma Raman 
Content Development Editor: Aditi Gour 
Technical Editor: Shweta Jadhav 

Copy Editor: Safis Editing 

Project Coordinator: Hardik Bhinde 
Proofreader: Safis Editing 

Indexer: Aishwarya Gangawane 

Graphics: Jason Monteiro 

Production Coordinator: Deepika Naik 


First published: June 2018 
Production reference: 1200618 
Published by Packt Publishing Ltd. 
Livery Place 

35 Livery Street 

Birmingham 

B3 2PB, UK. 

ISBN 978-1-78934-278-9 


www.packtpub. com 





“waMapt 


mapt.io 


Mapt is an online digital library that gives you full 
access to over 5,000 books and videos, as well as 
industry leading tools to help you plan your personal 
development and advance your career. For more 
information, please visit our website. 


Why subscribe? 


Spend less time learning and more time coding 
with practical eBooks and Videos from over 
4,000 industry professionals 


Improve your learning with Skill Plans built 
especially for you 


Get a free eBook or video every month 
Mapt is fully searchable 


Copy and paste, print, and bookmark content 


PacktPub.com 


Did you know that Packt offers eBook versions of every 
book published, with PDF and ePub files available? You 
can upgrade to the eBook version at ww.PacktPub.con and as 
a print book customer, you are entitled to a discount 
on the eBook copy. Get in touch with us at 

service@packtpub. com for more details. 


At ww.PacktPub.com, you Can also read a collection of free 
technical articles, sign up for a range of free 
newsletters, and receive exclusive discounts and offers 
on Packt books and eBooks. 





About the author 


Charit Mishra is an ICS/SCADA professional, working 
as a security architect for critical infrastructure across 
several industries, including oil and gas, mining, 
utilities, renewable energy, transportation, and 
telecom. He has been involved in leading and 
executing complex projects involving the extensive 
application of security standards, frameworks, and 
technologies. A postgraduate in computer science, 
Charit's profile boasts of leading industry certifications 
such as OSCP, CEH, CompTIA Security+ , and CCNA 
R&S. Moreover, he regularly delivers professional 
training and knowledge sessions on critical 
infrastructure security internationally. 


Ab out the reviewer 


Anish has a YouTube channel named Zariga Tongy 
where he loves to post videos on security, hacking and 
other cloud related technology. 


What this book covers 


chapter 1, InStalling Wireshark, will provide you with an 
introduction to the basics of the TCP/IP model and a 
step-by-step walk-through of the installation of 
Wireshark on your favorite operating system. 


chapter 2, Introduction to Wireshark and Packet 
Analysis, will help you understand the basics and 
science behind packet analysis, as Wireshark come in 
handy and proves to be a Swiss Army knife for 
professionals dealing with network, security, and 
digital forensics. In this chapter, you will also 
understand the trick of placing the sniffer in a 
strategic location to get most out of your network. 


Chapter 3, Filtering Our Way in Wireshark, will help you 
identify and apply the Wireshark filters, namely the 
capturing and displaying filters. Filtering provides a 
powerful way to capture or see the traffic you desire; 
it's an effective way to remove the noise from the 
stream of packets we desire to analyze. 


chapter 4, ANalyzing Application Layer Protocols, will help 
you understand the approach and methodology for 
analyzing application layer protocols such as HTTP 
SMTP FTP, and DNS through Wireshark. As we know, 
application layer protocols typically interface between 
a client and a server. It is critical to understand the 
structure and behavior of application layer protocols 
packets in order to identify anomalies with efficiency. 


chapter 5, Analyzing the Transport Layer Protocols 
TCP/UDP, will help you understand the underlying 
network technology, enabling the movement of 
network packets across routing infrastructures 
through the analysis of transport layer protocols such 
as TCP and UDP. TCP and UDP are the basis of 
networking protocol, and it is important to understand 
their structure and behavior. 


chapter 6, Network Security Packet Analysis, will guide 
you through using Wireshark to analyze security 
issues, such as analyzing malware traffic and 
footprinting attempts in your network. 


chapter 7, Analyzing Traffic in Thin Air, will help you in 
understand the methodology and approach involved in 
performing wireless packet analysis. This chapter 
shows you how to analyze wireless traffic and pinpoint 
any problems that may follow. We will also learn the 
cool trick of decrypting wireless traffic using 
Wireshark. 


chapter 8, Mastering the Advanced Features of 
Wireshark, will provide you with insight into the 
advanced options and elements available in Wireshark, 
such as a Statistics menu, and will also provide a brief 
and summarized approach on how to work with 
command-line packet sniffing applications, such as 
Tshark. 
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Preface 


Wireshark is the world's most popular free and open 
source protocol analyzer, and it is commonly used by 
networking and security professionals for 
troubleshooting, analysis, protocol development, and 
forensics. The primary objective of Wireshark is to 
capture network traffic and display the packet data in, 
as detailed a way as possible. It helps professionals 
view the content of network traffic on a microscopic 
level. 


This book is written from the standpoint of using 
Wireshark and learning how network protocols 
function and provides a practical approach to 
conducting protocol analysis, troubleshooting network 
anomalies, and examining security issues. I have tried 
to depict common scenarios that you may come across 
in day-to-day operations through practical 
demonstration wherever possible to help you 
understand the concepts better. By reading this book, 
you will learn how to install Wireshark, work with 
Wireshark GUI elements, and learn some advanced 
features behind the scenes, such as the filtering 
options, the statistics menu, and decrypting wireless 
and encrypting traffic. You can be the superhero of 
your team who helps resolve connectivity issues, 
network administration tasks, and computer forensics 
because Packets Are Life. If your routine job requires 
dealing with computer networks and security, then this 
book will give you a strong head start. Happy sniffing! 





Who this book ts for 


This book is for students/professionals who have basic 
experience and knowledge of the networking and who 
want to get up to speed with Wireshark in no time. 
This book will take you from the installation to the 
usage of commonly used tools/tricks. The book will get 
you comfortable with the GUI elements of Wireshark 
and explain the fundamentals of the science behind 
protocol analysis. 


To get the most out of 
this book 


e Basic understanding of networking protocols, 
OSI and TCP/IP model 


e Acomputer system with a basic internet 
connection to follow the depicted scenarios 


Download the color 
images 


We also provide a PDF file that has color images of the 
screenshots/diagrams used in this book. You can 
download it here: https: //ww.packtpub.com/sites/default/files/download 
s/Wireshark2QuickStartGuide ColorImages.pdf. 


Conventions used 


There are a number of text conventions used 
throughout this book. 


CodeIntext: Indicates code words in text, database table 
names, folder names, filenames, file extensions, 
pathnames, dummy URLs, user input, and Twitter 
handles. Here is an example: "Mount the downloaded 
WebStorm-10*.dng disk image file as another disk in your 
system." 


Bold: Indicates a new term, an important word, or 
words that you see onscreen. For example, words in 
menus or dialog boxes appear in the text like this. 
Here is an example: "Select System info from the 
Administration panel." 


Warnings or important notes appear like this. 


Tips and tricks appear like this. 


Get in touch 


Feedback from our readers is always welcome. 


General feedback: Email feedbackepacktpub.con and mention 
the book title in the subject of your message. If you 
have questions about any aspect of this book, please 
email us at questions@packtpub. com. 


Errata: Although we have taken every care to ensure 
the accuracy of our content, mistakes do happen. If 
you have found a mistake in this book, we would be 
grateful if you would report this to us. Please visit ww.pac 
ktpub.com/submit-errata, Selecting your book, clicking on the 
Errata Submission Form link, and entering the details. 


Piracy: If you come across any illegal copies of our 
works in any form on the Internet, we would be 
grateful if you would provide us with the location 
address or website name. Please contact us at 
copyright@packtpub. com with a link to the material. 


If you are interested in becoming an author: If 
there is a topic that you have expertise in and you are 
interested in either writing or contributing to a book, 
please visit authors. packtpub.com. 


Reviews 


Please leave a review. Once you have read and used 
this book, why not leave a review on the site that you 
purchased it from? Potential readers can then see and 
use your unbiased opinion to make purchase decisions, 
we at Packt can understand what you think about our 
products, and our authors can see your feedback on 
their book. Thank you! 


For more information about Packt, please 
visit packtpub.com. 


Installing Wireshark 


This chapter provides you with an introduction to the 
basics of the TCP/IP model and a step-by-step 
walkthrough of how to install Wireshark on your 
favorite operating system. You will be introduced to 
the following topics: 


e What is Wireshark? 


e A brief overview of the TCP/IP model 


Installing and running Wireshark on different 
platforms 


Troubleshooting common installation errors 


Introduction to 
Wireshark 


Wireshark is an advanced network and protocol 
analyser, it lets you visualize network's activity in 
graphical form, and assists professionals in debugging 
network-level issues. Wireshark enhances the ability of 
network and security professionals by providing 
detailed insight into the network traffic. However, 
Wireshark is also used by malicious users to sniff 
network traffic in order to obtain sensitive data in the 
form of plain text. 


Why use Wireshark? 


Many people, including myself, are obsessed with the 
simplicity of the packet-capturing features that 
Wireshark provides us with. Let's quickly go through a 
few of the reasons why most professionals prefer 
Wireshark to other packet sniffers: 


e User friendly: The interface of Wireshark is 
easy to use and understand, tools & features are 
very well organized and represented. 


e Robustness: Wireshark is capable of handling 
enormous volumes of network traffic with ease. 


e Platform independent: Wireshark is available 
for different flavors of operating system, 
whether Windows, Linux, and Macintosh. 


Filters: There are two kinds of filtering options 
available in Wireshark: 


e You choose what to capture (capture 
filters) 


e You choose what to display after you've 
captured (display filters) 


e Cost: Wireshark is a free and open source 
packet analyzer that is developed and 
maintained by a dedicated community of 
professionals. Wireshark also offers a few paid 
professional applications as well. For more 
details, refer to Wireshark's official website http 


s: //ww.wireshark.org/. 


e Support: Wireshark is being continuously 
developed by a group of contributors that are 
scattered around the globe. We can sign up to 
Wireshark's mailing list or we can get help from 
the online documentation, which can be 
accessed through the GUI itself. Various other 
online forums are also available for you to get 
the most effective help; go to Google Paid 
Wireshark Support to learn more about the 
available support. 


The tnstallation process 


The installation of Wireshark is very simple and easy to 
follow. Go through the following steps to install it on 
your system: 


1. The recipes and examples in this book will be for 
use on a Macintosh and Windows PC; for other 
operating systems, the installation is the same. 
Some OSes, such as Kali Linux, come with a 
preinstalled version of Wireshark. 

2. Once you have located the correct version of 
Wireshark for your platform (Wireshark 2.6.1 
Intel 64.dmg), install Wireshark by following the 
wizard. 

3. Restart the computer after completion of the 
installation process to commit the changes that 
were made. 

4. Double-click the Wireshark icon on your desktop 
to the run the application: 
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Troubleshooting 
common installation 
errors 


Go through the following simple checklist to ensure 
that you are able to run Wireshark successfully (make 
sure that all of these criterias are met): 


You have downloaded Wireshark from known 
and trusted source only 


You have administrative privileges to run 
Wireshark 


The installation of Wireshark and the Winpcap 
driver has been completed successfully without 
any exceptions 


You are connected to the network that you want 
to capture network traffic from 


If you are trying to sniff using a virtual machine, 
ensure that you have set your network adapter 
to bridged mode 


Restart your machine to ensure the changes 
have been applied after successful installation of 
Wireshark 


Your NIC card supports promiscuous mode 
sniffing (when needed) 


You can see all of the interfaces (wired, wireless, 
and logical) on the home screen of Wireshark 


The line graph followed by the interface name 
shows activity on the Homescreen 


Also, you have legal permissions to capture 
network traffic 


A brief overview of the 
TCP/IP model 


The world of network communication is governed by a 
set of protocols (rules and regulations) in order to 
function as intended. Protocols govern the 
transmission of network packets/segments/frames over 
a communication channel between endpoints. In order 
to understand how network packets stick together, 
forming a stream of traffic, we need to understand the 
basics of the networking that is the TCP/IP model. The 
TCP/IP model was originally known as the DoD model, 
a project that was regulated by the United States 
Department of Defense. All of the communication that 
we witness over the internet and other networks 
happens only through TCP/IP. 


The TCP/IP model takes care of every part of packet's 
life cycle, namely, how a packet comes to life, how a 
packet is generated, how information pertaining to 
packet gets attached data payload (PDU), how it is 
routed through intermediary nodes, linking with other 
packets and so on. 


It is strongly recommended to do some self-study on 
TCP/IP and how it functions, before you proceed 
ahead, as this book requires decent amount of 
familiarity with protocols. 


The layers in the TCP/IP 
model 


The TCP/IP model comprises four layers, as shown in 
the following diagram. Each layer has a specific 
purpose to fulfill and utilizes a set of protocols to 
facilitate communications. Every protocol in every 
layer has a specific purpose: 





The first layer is the Application Layer, which 
directly interacts with users and subsequent layers 
and protocols; it is primarily concerned with the 
representation of the data in a understandable format 
to the user. The application layer also keeps track of 
user sessions, monitoring who is connected; it uses a 
set of protocols that helps to interface with users and 


other layers in the TCP/IP model. Some popular 
protocols in the Application Layer are as follows: 


e Hypertext Transfer Protocol (HTTP) 
e File Transfer Protocol! (FTP) 


e Simple Network Management Protocol 
(SNMP) 


e Simple Mail Transfer Protocol (SMTP) 


The second layer is the Transport Layer. The purpose 
of this layer is to create sockets (a combination of the 
port and IP address) in order to let two endpoints 
communicate. Sockets facilitate the creation of 
multiple distinct connections between two or more 
devices (more than one tab can be opened in Chrome). 


An IP address is required for communication between 
devices in different networks/segments (such as is 
used between two router interfaces or communication 
over the internet). It can also be used in local area 
network (LAN) communication, and is established 
over physical addresses (MAC). Apart from the 
restricted range of port numbers, operating systems 
and applications can choose a random port (other than 
ports 1 to 1013) for communication. 


The transport layer also serves as a backbone for the 
communication. The two most critical protocols that 
work in this layer are the TCP and UDP: 


e The TCP is a connection-oriented protocol, also 
called a reliable protocol. Firstly, a dedicated 
communication channel is established between 
the endpoints, which is then followed by data 
transmission. Equally partitioned chunks are 
transmitted from the source, and the receiving 
end sends an acknowledgement for every packet 
received. The side that is sending the data 
resends the packet if an acknowledgement is not 
received within a stated time frame. 


e The UDP is a connectionless protocol and is 
often called an unreliable communication form. 
In the UDP, no dedicated channel is established, 
which also makes it a simpler and faster way of 
communication. There are also no 
acknowledgement packets sent by the 
endpoints. For example, if you are playing an 
online game, the loss of a few packets over the 
communication channel is not going to hamper 
your gaming experience because the number of 
packets coming through is huge, and a few 
missing packets will not make much difference 
to the overall quality of the network stream. 


The third layer is the Internet Layer, which is 
primarily concerned with routing and movement of 
data between networks. The primary protocol that 
works in this layer is the IP (Internet Protocol). The 
IP provides the network packets with the routing 


capability that they need in order to reach their 
destination. Other protocols included in this layer are 
the ICMP and IGMP. 


The fourth and final layer is the Link Layer (often 
called the network interface layer). It interfaces with 
the physical network hardware. There are no protocols 
specified in this layer by the TCP/IP; however, several 
protocols are implemented, such as the Address 
Resolution Protocol (ARP) and the Point to 

Point Protocol(PPP). This layer is concerned with 
how information travels inside the communication 
channel (wired or wireless). The link layer is 
responsible for establishing and terminating the 
connection, as well as converting the signals from 
analog to digital and vice versa. Devices such as 
bridges and switches operate in this layer. 


As data progresses from the application layer to the 
link layer, several bits of information are attached to 
the data in the form of headers or footers, which allow 
different layers of the TCP/IP to communicate with 
each other. The process of adding these extra bits is 
called data encapsulation, and in this process, a 
protocol data unit (PDU) is created at the end of the 
networking process (passing through the application 
to the link layer). 


PDU consists of the data along with network 
addressing and protocol information that gets 
attached as part of the header or footer. By the time 
PDU reaches the bottom-most layer, it is embedded 
with all the required information necessary for 
transmission. Once the PDU reaches the destination, 
the attached header and footer PDU elements are 


ripped off one by one as it passes through each layer of 
the TCP/IP model and progresses upward in the model. 


The following diagram depicts the process of 
encapsulation: 
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Summary 


In this chapter, we looked at the basic networking 
concepts that you need to know, along with an 
introduction to Wireshark. Wireshark is a protocol 
analyzer that is used worldwide by technology 
professionals to capture and analyze network-level 
packets. 


We also learned about the TCP/IP model. The TCP/IP 
model has four layers: the application layer, transport 
layer, network layer, and the link layer. Data is 
encapsulated as it passes from one layer to another; 
the resulting packet at the bottom is called a complete 
PDU. 


The TCP is a reliable protocol because 
acknowledgements are sent as part of its process, 
whereas the UDP is an unreliable protocol because no 
acknowledgements are sent. 


To install Wireshark, you just need to Visit http: /~ww.wiresha 
rk.org and then download the appropriate version for 
your operating system. 


Troubleshooting your Wireshark can be done by 
ensuring that the network is working fine, that you 
have the full rights required to install and run the 
application, and that the installation had completed 
without any exceptions. 





Introduction to 
Wireshark and Packet 
Analysis 


This chapter will help you to understand the basics and 
science behind packet analysis. Wireshark comes in 
very handy and proves something of a Swiss knife for 
professionals dealing with network, security, and 
digital forensic roles. You will learn about the following 
topics in this chapter: 

e Introduction to Wireshark 

e How Wireshark works 

e Capturing methodologies 


e Understanding the GUI of Wireshark 


e Starting our first capture 


What is Wireshark? 


Wireshark is a packet-sniffing application that is used 
by IT professionals for a diverse set of requirements 
(including forensics, troubleshooting, and enhancing 
network performance). You can download it for free 
from https: //www.wireshark.org/download.html, where it is available 
for the majority of platforms, including Linux, 
Macintosh, and Windows. 


Packet sniffing is also referred to as tapping into the 
wire, which basically involves reading pieces of 
information traveling in a communication channel. 
Considerations such as placement of sniffer, protocols 
to be analyzed, and communication channel type need 
to be assessed before capturing network packets. 


How Wireshark works 


Wireshark collects network traffic from the wire 
through the computer's network interface, running in 
promiscuous mode (if needed), to inspect and display 
information related to protocols, IP addresses, ports, 
headers, and packet length. The following diagram is 
an illustration of how all the elements work together to 
display packet-level information to the user (source: ntt 


ps: //www.wireshark.org): 
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Wireshark comes with the Winpcap/libcap driver, 
which enables NIC to the run in promiscuous mode; 
the only time you don't have to sniff in promiscuous 
mode is when the packets are directly, intentionally 
destined/generated to and/or from your device. 


On operating systems, you should have privileges to 
run Wireshark. There are three processes that every 
protocol analyzer follows: collect, convert, and analyze. 
These are described as follows: 


e Collect: Choose an interface to listen to traffic 
and capture network packets. 


e Convert: Increase the readability of non- 
human-readable data. Packets are converted to 
easily understood information through a GUI. 


e Analyze: Analyze network traffic pertaining to 
the packets, protocols, raw data and more 
through the usage of statistical and graphical 
features. 


As discussed in the previous chapter, protocols are the 
set of rules and regulations that govern the process of 
communication between two network devices and 
control the environment under which they operate. 


An introduction to 
packet analysis with 
Wireshark 


Packet/traffic analysis deals with the study of network 
traffic, where the objective is to understand the 
structure, movement, and behavior of packets. Packet 
analysis is performed over live traffic or done over an 
already captured stream of traffic. 


Numerous issues arise in day-to-day networking 
infrastructures, and if you are responsible for handling 
the network or security of your digital environment, 
you need to equip yourself with troubleshooting and 
analytical tools. Most of the issues escalate and are 
rectified at the packet level in networking. Issues 
arising at the packet level can gradually end up 
disrupting critical business communication, leading to 
loss of revenue. Even the best networking hardware 
utilizing the most advanced and secure set of protocols 
and services can go against you or behave abnormally. 
To perform a root cause analysis in such situations, you 
might need to dig down to the packet level in order to 
understand the anomaly. Packet analysis can be used 
for the following purposes: 


e To analyze network issues by looking into the 
packets and their headers to gain better 
insights. 


To detect and analyze network intrusion 
attempts through filtering patterns and 
signatures. 


To detect network misuse by internal or external 
users by establishing firewall rules in your 
security appliance and then monitoring those 
rules. 


To study and isolate exploited systems so that 
the affected system doesn't become a pivot 
point. 


To monitor and analyze data in motion as it 
travels live in the wires of your network. 


To have better control over the allowed and 
restricted categories of information traveling in 
your network. For instance, say you want to 
create a rule in the firewall that will block 
access to torrent sites (peer-to-peer file 
sharing). Blocking access to them can be done 
from your manageable router through access 
lists also, but the origin of such packets can be 
identified and validated through traffic analysis. 


To gather and report network statistics by 
filtering packet trails. 


To learn who is on a live network and what they 
are doing (they may be consuming network 
bandwidth or trying to connect to restricted 


websites), and to learn whether someone is 
trying to bypass the network restrictions you 
configured. 


e To debug client/server communications so that 
all the requests and replies communicated on 
your network can be audited. 


e To identify applications that are sitting in the 
corner of your network and consuming the 
bandwidth. They might be making your network 
insecure, unresponsive, or visible to the public 
network. 


e To debug network protocol implementations and 
any anomalies being generated due to 
unintentional misconfigurations errors or 
human error. 


e To identify abnormal/malicious traffic patterns 
that your network, then to analyze, 
control/supervise, and make yourself ready for 
such events. 


When performing packet analysis, the things to be 
considered are as follows: 


e The protocol(s) to be interpreted 


e Whether you need to capture traffic from all 
sources and all destinations 


e Placing your sniffer adequately 


e Capturing traffic pertaining to a particular port 
or service to avoid unwanted noise 


You should record and build use cases pertaining to 
the network traffic pattern and behavior. Use cases 
may assist engineers in troubleshooting network 
issues. 


Packet analyzers can interpret most networking 
protocols (such as IP and ICMP), transport-layer 
protocols (such as TCP and UDP), and application-layer 
protocols (such as DNS and HTTP). 


How to do packet 
analysis 


Network packets are captured in raw binary form, and 
passed through the wiretap library and capture 
engine, and then to the core engine, with 

its dissector plugins and filters. The translated data is 
then displayed in packet frames through Graphical 
Toolkit (GTK). 


Capturing 
methodologies 


In order to capture the right set of a packets stream, 
you would need to know where to place your protocol 
analyser. Depending on the requirements (source of 
packets, number of packets, type of packets, and 
more), a protocol analyzer needs to be placed ata 
certain point in the network. Also, a few configuration 
changes in a network device may be necessary, such as 
switch configuration changes (mirroring is done in 
network switches to capture packets from one or more 
sources). The following sub sections discuss a few 
means of assessing the best way of configuring 
protocol analyses in certain types of topology. 


Hub-based networks 


It is relatively easy to sniff in a hub-based network 
topology, because you've got the freedom to place the 
sniffer at any place you want, as hubs are designed to 
broadcast each and every packet to all connected 
devices. 


However, due to such design deficiencies, hub-based 
network topologies face issues in terms of overall 
performance. Network hubs do not have much 
capability in terms of prioritizing or forwarding traffic 
to specific ports only. They often become victims of 
collision-related problems. For instance, if more than 
one device connected to a hub start sending data at 
the same time, there is a high a probability that the 
packets will collide and fail to reach their destination. 
The sending side will be informed of dropped packets, 
which will then be re-sent, but it will cost the network 
and its administrator in time, improper bandwidth 
utilization, and performance issues. 


The switched 
environment 


Due to relatively few restrictions present in switch- 
based infrastructures, packet analysis becomes quite 
challenging. Like hubs, switches do not broadcast the 
packets to every network port except the port the 
packet is received from. They learn the physical 
addresses of devices through the ARP (address 
resolution protocol) and populate a list of port 
numbers with corresponding MAC addresses. Even so, 
through some hardware or configurational changes it 
is possible to capture packets from other ports. The 
two most popular techniques are hubbing out and port 
mirroring. 


In order to capture the stream of packets coming from 
one or more ports, configure port mirroring using the 
switch configuration console. Most intelligent switches 
give the option to configure it through an easy-to- 
understand graphical interface. 


Let's make it simpler for you with a logical illustration. 
For instance, let's assume that we have a 24—port 
switch and eight PCs, which are connected to different 
switch ports. We can place our sniffer (Wireshark PC) 
in any of the free switch ports and then configure port 
mirroring, which will copy all the traffic from the 
desired device we want to sniff to the port of our 
choice. The following screenshot shows the set of 


commands used in a Cisco Switch to configure port 
mirroring: 





So, let's understand it better: in the previous 
screenshot, I have configured what to listen to all the 
packets originating from port fao/2 to port fao/4. Port fao/2 
will be the target machine and port fao/4 will be a 
Wireshark machine. 


Once this is completely configured, we will be able to 
easily sniff and analyze network packets flowing back 
and forth from port fao/z. This technique is one of the 
easiest to configure; the only thing you need to know 
beforehand is how to work with network devices. 


The following diagram depicts a simple demonstration 
of port mirroring: 






PC running 
wireshark 





Port mirroring 


Hubbing out is feasible when your switch doesn't 
support port mirroring. To use the technique, you must 
actually unplug the target PC from the switched 
network, then plug your hub to the switch, and then 
connect your analyzer and target device to the hub so 
the target device becomes part of the same network. 


Now the protocol analyzer and the target machine are 
part of the same broadcast domain. The following 
diagram will make it easier for us to understand the 
process precisely and in a simpler way: 


Hubbing Out 





* mirroring not possible protocol 
Analyser 


Hubbing out 


ARP poisoning 


Poisoning the ARP table entries of a device and then 
forwarding them through your machine is one 
unethical way of capturing the traffic from the target 
machine. 


Let's say, for example, we have the default gateway at 
IP 192.168.1.1 and one client machine configured at IP 
192.168.1.2. Both of these devices are maintaining local 
ARP cache entries. That enables them to send packets 
over the LAN. Now, the Wireshark (use arpspoof OF ettercap 
to poison the ARP entries) machine at IP 192.168.1.3 will 
poison the ARP cache entries by flooding the client and 
gateway machine with multiple ARP packets, stating to 
the client PC that the default gateway has been 
changed to IP 192.168.1.3 and stating the gateway that 
the client is now at IP 192.168.1.3; this will make every 
packet go through the Wireshark machine. 


The command to view the ARP cache in your 
PC/router/server, which will display MAC addresses 
associated for a particular IP address, is arp -a. Have a 
look at the normal ARP entries: 


Attacker 


ARP Cache 


192.69.1.2 





Normal Senano 
ARP Cache ARP Cache 


IP MAC IP MAC 
server | 192.68.1.1 | AA:BB:CC Client | 192.69.1.2 | AA:BB:EE 





Attacker | 192.68.1.3 | AA:BB:DD Attacker | 192.68.1.3 | AA:BB:DD 


ARP poisoning (the normal scenario) 


Here is how the entries will look before the ARP is 
poisoned: 


Before ARP is Poisoned 


192.68.1.1 - (Server) 
192.68.1.2 - AA:BB:EE 
192.68.1.3 - AA:BB:DD 


192.68.1.2 - (Client) 
192.68.1.1 - AA:BB:CC 
192.68.1.3 - AA:BB:DD 


192.68.1.3 - (Attacker) 
192.68.1.1 - AA:BB:CC 
192.68.1.2 - AA:BB:EE 
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Now that you've understood what the ARP is and how 
it works, we can try to poison the ARP Cache of both 


the default gateway and the client with the attacker's 
MAC address. In simple terms, we will replace the 
client's MAC address in the default gateway's ARP 
cache with the attacker's MAC address. We will do the 
same in the client's MAC address, replacing the default 
gateway's MAC address with the attacker's MAC 
address. As a result, every packet destined to the 
client from the default gateway back and forth will be 
sent through the attacker's machine. Below are the 
ARP entries from the client, the server, and the 
attacking machine after a successful poisoning attack. 


After ARP is Poisoned 


192.68.1.1 - (Server) 
192.68.1.2 - AA:BB:DD 
192.68.1.3 - AA:BB:DD 


192.68.1.2 - (Client) 
192.68.1.1 - AA:BB:DD 
192.68.1.3 - AA:BB:DD 


192.68.1.3 - (Attacker) 
192.68.1.1 - AA:BB:CC 
192.68.1.2 - AA:BB:EE 


The poisoned machines will not be able to determine 
whether their ARP has been modified unless checked 
proactively. The following diagram depicts the ARP 
table entries of all three systems involved in the MiTM 
attack scenario: 


Attacker ARP Cache 
IP MAC 


Client | 192.69.1.2 | AA:BB:EE 
Sener | 192.68.1.1 | AA:BB:CC 








ARP Poisoning Scenario 
ARP Cache So ARP Cache 
ip MAC IP MAC 


19? 168.11 Server | 192,168.11 | AA:BB:DD 
Attacker | 19216813 | AA:BB:DD 





Attacker | 192,168.13 


ARP poisoning (the poisoned scenario) 


Other than these two techniques, there is a variety of 
hardware available on the market popularly known as 
taps, which can be placed between any two devices to 
sniff and analyze the traffic. Though this technique is 
effective in capturing network traffic in some 
scenarios, it should only be practiced or deployed in an 
authorized and controlled environment, because of its 
malicious nature. 


Passing through routers 


When dealing with routed environments, the 
important aspect of packet analysis would be to place 
our sniffer at the suitable place from where we can 
capture the desired traffic packets. Dealing with 
routed structures demands more skills in terms of 
networking technologies, and certainly in terms of 
routers. Consider the following hypothetical routed 
environment for the sake of understanding. 


Router 1, router 2, and router 3 are working together; 
each of them handles traffic for at least 2-3 PCs. 
Router 1 is acting as a root node while controlling 
routing for its child networked nodes (router 2 and 
router 3). 


Router 3 PCs are not able to connect to router 1 PCs. 
To resolve this issue, the admin places a sniffer 
(protocol analyzer) inside the router 3 area, and starts 
analyzing the traffic, but is not able to figure out the 
anomaly that is causing downtime. The admin decides 
to change the protocol analyzer location and moves to 
the router 1 area, and now follows similar steps for 
troubleshooting. After a while, they figure out what the 
issue was and troubleshoot it successfully. 


The conclusion is that placing the sniffer in your 
networked infrastructure is quite a critical decision 
and task. 


After reading this, I hope we've a fair amount of 
knowledge on how protocol analyses are done in 
certain topologies. Now, let's see what the Wireshark 
interface looks like, and how we can initiate capturing 
network packets. 


If you do not have Wireshark installed, you can geta 
free COpy from https: //ww.wireshark.org/download.html. To walk 
through the demonstrations in this book, you also need 
to be familiar with the interface. 


The Wireshark GUI 


Before we discuss its awesome features, let's talk 
about some of critical events in the Wireshark domain. 


Wireshark was built during the late 1990s. Gerald 
Combs, a young college graduate from Kansas City, 
developed Ethereal (the basic version of Wireshark), 
and by the time Combs developed this awesome 
invention, he had landed himself a job. After a few 
years of service, Combs decided to quit his job and 
pursue his dreams by developing Ethereal further. 
Unfortunately, as per the legal terms, Combs' invention 
was part of the company's proprietary software. 
Despite this, Combs left the job and started working on 
the new version of Ethereal, which he titled Wireshark. 
Since 2006, Wireshark has been in active development 
and is being used worldwide. It supports more than 
800 protocols both corporate IT and ICS (industrial 
control system). 


Before we go ahead and start the first capture, we 
need to get a bit familiar with the options and menus 
available. 


There are six main parts in the Wireshark GUI, which 
are explained as follows: 


e Menu Bar: This represents tools in a generalized 
form, which are organized 


in the Applications menu. 


e Main Tool Bar: This consists of the frequently 
used tools/features that offer efficient utilization 
of the software. 


e Packet List Pane: This displays all the packets 
getting captured by Wireshark. 


e Packet Details Pane: This is used to view details 
pertaining to the selected packet from the 
Packet List Pane. Detailed information regarding 
the packets is divided into categories 
corresponding to each layer of the TCP/IP 
model. This can be used to view source and 
destination IP addresses and different protocols 
used for communication arranged in the bottom- 
to-top approach (link layer to application layer). 


e Bytes Pane: This shows the data in the packets 
in the form of hex bytes 
and their corresponding ASCII values; it shows 
the values in the form 
in which they travel in the wires. 


e Status Bar: This displays details such as total 
packets captured. 


The following screenshot will help you to identify 
different sections in the application; please make sure 
that you get yourself acquainted with all of them 
before proceeding further: 


10,000000000 — 172,20,10,7 17,178, 104, 38 Ter 1414 [TCP segment of a reassembled POU) 
20,000001000 = 172.20.10.7 17,178, 104, 38 TCP 1414 [TCP segment of a reassembled POU) 
30,000001000 | 172,20,10.7 17,178, 104, 38 TLSv1.2 438 Application Data 

4 1, 666233000 17, 178, 104, 38 172,20,10.7 TCP 54 44353067 [ACK] Seg 


{ 


Packet List Pane 


6 1,691123000 17,178, 104. 38 172,20,10.7 TCP 1414 [TCP segment of a 


7 1,691257000 17,178, 104, 38 172,20,10,7 TLSv1.2 57 Application Data 

8 1,691323000 172.20, 10.7 17,178, 104, 38 TCP 54 53067443 [ACK] Seq=3105 Ack=1361 Win=8149 Len=0 

9 1,691392000 — 172.20,10.7 17,178, 104,38 TCP 54 53067-443 [ACK] Seq=3105 Ack=1364 Win=8149 Len=0 

10 6, 283488000 83, 166, 169, 231 172,20,10.7 TLSv1.2 97 Encrypted Alert 

11 6, 283593000 172,20. 10.7 83, 166,169, 231 TCP 66 530424443 [ACK] Seq=] Ack=32 Win=4095 Len=0 TSval=822128 


13 6, 307390000 172,20, 10,7 83, 166, 169. 231 TP 66 53042-443 [ACK] Seq=] Ack=33 Win=4096 Len=) TSval=822128 
14 6, 307491000 83, 166, 169, 231 172,20,10.7 TLSvL.2 97 Encrypted Alert 
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) Frame 5; 54 bytes on wire (432 bits), 54 bytes captured (432 bits) on interface 0 
) Ethernet II, Src: 4a:74:6e:ba:d0:64 (4a:74:6e:ba:d0:64), Dst: Apple b9:53:ec (d8:bb:2c:b9:53:ec) Packat Details P 
) Internet Protocol Version 4, Src: 17.178,104,38 (17,178,104, 38), Ost; 172,20,10,7 (172,20, 10.7) aceet Details Vane 


) Transmission Control Protocol, Src Port: 443 (443), Dst Port: 53067 (53067), Seq: 1, Ack: 3105, Len: 0 





free) 











0010 00 28 80 ea 0000 8 06 21 ca 2112 68 % ac r ere bah. 


0020 0a 07 01 bb cf 4b 94 ec 4c 31 26 la ae 08 5010 ..., Ki. L1G.,.P. 
0030 Od 39 ec 60 00 00 De ve 













Status Bar 


‘Profile: Default =, 


W//File: “/var/folders/ck/31tvm... 4 Packets: 44 - Displayed: 44 (100.0%) » Dropped: 0 (0.0%) 





Within the toolbar area, we have a few useful tools. I 
would like to give you a brief overview of some of 
them: 


C3) 


e  : Choose an interface for listening 


© : Customize the capture process (interface, 
filters, and so on) 


4\@ 2 


process 


: Start/stop/restart the capturing 


— : Open a saved capture file 


: Save the current capture in a file 


we 
: Reload the current capture file 


: Close the current capture file 

@: Go to previous packet 

* . Go to next packet 

* : Go to a specific packet number 

eS. Toggle color coding for the packets on/off 


EF Toggle the auto scroll on/off 


ti) 
“™ . Zoom in, zoom out, and reset 
zoom to the default 





“ : Change the color coding as per 
requirements 


° : Narrow down the window to capture 
packets 

° i) : Configure display filters to only see what is 
required 


Even after selecting the interface, there can 
sometimes not be any packets listed in the list pane; 
there can be multiple reasons for this, some of which 
are as follows: 


e You do not have any network activity 


e Your interface is not able to capture the desired 
packets, due to privileges 


e You do not have promiscuous mode activated or 
do not have an option for promiscuous mode 


Once you click on the Capture button in the tool pane, 
Wireshark will start capturing and you will be able to 
see some traffic activity colored with different codes, 
protocol names, packet numbers, IP addresses, and so 
on: 


000 Calving rom WF ent (Weeshark 1126 (.126-0.getloe fom master, 12) 
file Edit ‘View Go Capture Analyze Statistics Telephony Tools Internals Help 


COANA BAX VH90FTS ERC QAN MRR G 
Filter + apes, Clear Apply Save 


No.  }Time Source Destination Protocol] Length| Info 
10,000000000 — 172,20.10.7 172.20.10.1 DNS 79 Standard query Oxa69f A qspl0-ssl, apple, com 
2 1,086453000 —172,20,10,7 172.20,10,1 ONS 79 Standard query Oxa69f A qspl0-ssl. apple, com 
3 1,089702000 172.20,10.1 172.20.10,7 ONS 190 Standard query response Oxa69f Se NAA 

























190 Standard query response Oxa69f CNAME gspl0-ssl. Ls-apple. coma 








§.1,125878000  172,20,10.1 172.20.10.7 ONS 

71, 748066000 172, 20,10,7 17.167, 194,205 TP 54 52086443 [ACK] Seq=] Ack=) Win=262144 Len=0 

81, 749286000 172,20, 10,7 17,167, 194, 205 $SL 244 Client Hello 

9 3,079270000 17, 167, 194, 205 172.20,10,7 TCP 1414 (TCP segment of a reassenbled POU) 

10 3,079341000 —172,20,10,7 17,167, 194, 205 Te 54 52086443 [ACK] Seq=191 Ack=136) Win=260768 Len=0 

11 3,079986000 17, 167, 194, 205 172,20,10,7 TCP 1414 (TCP seqnent of a reassenbled POU) 

123,080086000 —172,20,10.7 17,167,194, 205 TCP 54 52086443 [ACK] Seqzl91 Ack=2721 Win=260768 Len=0 

13 3080365000 17,167, 194, 205 172.20,10,7 Te 1414 (TCP segment of @ reassembled POU) L 
14 3,080372000 17,167, 194, 205 172.20.10,7 Tvl 412 Server Hello, Certificate, Server Hello Done ' 





| fran 18s 168, bytes on wire (13M4 bits)" 168 bytes Captired 11384 bits) on dnterface’a” 

b Ethernet 1, Src; 4a;74:6esba:d0;64 (4a:74:Gesba:d0:64), Ost; Apple_b9; 53; ec (¢8:bb:2c;b9:53;ec) 
b Internet Protocol Version 4, Src: 172.20,10,1 (172,20.10.1), Ost: 172.20,10,7 (172.20, 10. 7) 

) User Datagram Protocol, Src Port: 53 (53), Dst Port; 52556 (52556) 

> Domain Nang System (response) 


ass 





ie 








OM Frame me aL “f ase §2 Tine §2 (100.0%) ‘Profile: Default 


The Wireshark capture screen 


Starting our first 
capture 


As you've been introduced to the basics of Wireshark 
and since you have learned how to install Wireshark, I 
feel you are ready to initiate your first capture. I will 
be guiding you through the following series of steps to 
start/stop/save your first Wireshark capture: 


1. Open the Wireshark application. 
2. Choose an interface to listen to. 


Before you click on Start, we have the Options button, 
which gives us the advantage of customizing the 
capture process; but for now, we will be using the 
default configuration: 


Wireshark « Capture Interfaces 


Input | Output — Options 











Interface Traffic Link-layer Header Promis« Snaplen (I Buffe! 
2 Ne theme efe 
> vboxnet0 Lona Ethernet v default 2 
> vmnetl AWWA Ethernet V default 2 
> vmneta —r_n—_r_M_A Ethernet V default 2 
> vmnetlO nM Ethernet ¥ default 2 
any annua Linux cooked ¥ default 2 
> Loopback: lo h »__\_. Ethernet v default 2 
bluetoothd ____ Bluetooth HCI UART transport layer plus pseudo-header ¥ default 2 
nflog Linux netfilter log messages v default 2 
nfqueue Raw IPv4 ¥ default 2 
usbmon] COLT 1 v default 2 
usbmon2 LT 1 v default 2 
Cisco remote capture: cisco _____ «Remote capture dependent DLT 
Random packet generator: randpkt Generator dependent DLT 
SSH remote capture: ssh _____sRemote capture dependent DLT 
UDP Listener remote capture: udpdump____—=s——— Exported PDUs 
f > 
¥ Enable promiscuous mode on all interfaces Manage Interfaces... 
Capture filter for selected interfaces: |{f |Enter a capture filter Compile BPFs 





Close Help 


The capture customization screen 


Below are the steps for the capture process: 


1. Click on the Start button to initiate the traffic 
Capilinre: 

2. Open a browser. 

3. Visit any website in your browser to generate 
some HTTP-based traffic: 


Bf Witeshark-GoDeep, X + v 


A () () F hips; wnwniresharkorg 


Bh ScaDA ise 





NEWS GetAcquaintedy GetHelpy Developy QurSponsor SharkFest 


= 
WIRESHARK 





The Wireshark website 


4. Switch back to the Wireshark screen; if 
everything goes well, you should be able to see 
numerous packets getting captured in your 
Wireshark GUI inside the Packet List Pane. 


5. To stop the capture, you can just click on the 
Stop capture button in the toolbar. area, or you 
can click on Stop under the Capture menu bar: 


000 \\ Capturing from WiFi: ont (Wirashark 1,126 (1,12.6-0-goottoo6 from master 12) 
File Edit View Go Meni Analyze Statistics Telephony Tools Internals Help 


OOdn (joiners, Crt) gp ti BG QQQR GMBH 


Option: trl 
Expression... Cleay Apply 


Filter A Start Ctrlal 


No, |Time (BSG) 
Restart Ctrl4R 






> 











20, 001055000" if Capture Filters. ARP 42 Who has 17,155,127, 223? Tell 172,20, 10,1 
a AEETORM a at h inter ARP 42 Who has 17,155, 127,222? Tell 172, 20,10, 
41, 2aynagny 7 NEESn Imertaces AP 42. has 17, 155,127,223? Tell 172,20.10. 
5 2,150384000 — 4a:74;6e; ba: dd; 64 Broadcast ARP 42. Who has 17,155,127, 222? Tell 172,20, 10,1 
6 2151348000 4a; 74; 6e;ba;d0:64 Broadcast ARP 42 Who has 17,155,127, 2237 Tell 172,20.10.1 
74, 300738000 4a; 74: 60:ba;d0:64 Broadcast ARP 42 Who has 17,155, 127,2227 Tell 172,20,10,1 
8 4, 301645000 4a; 74; 6e; ba: dd: 64 Broadcast ARP 42 Who has 17,155, 127,223? Tell 172,20, 10,1 
9 7,759507000 —172,20,10,7 172,20.10,1 WP 46 Source port; 65439 Destination port: 192 
10.8, 263903000 172,20,10,7 172,20.10.1 OP 46 Source port: 65439 Destination port; 192 
1213,906202000 172,20, 10,7 172,20,10.1 ONS 76 Standard query 0x0628 A www, google, co, tn 
13 13,906725000 172, 20,10,7 172,20, 10,1 DNS 75 Standard query Oxc591 A apis, google, com 
14 13,906913000 172,20, 10,7 172,20.10,1 DNS 79 Standard query Oxdab? A clients5, google, com ' 


snes 


‘) Frame 1: 42 bytes on wire (336 bits), 42 bytes captured (336 bits) on interface 0 
‘D Ethernet 11, Src: 4a:74;6e:baid0;64 (4a;74:6e:ba:d0;64), Ost; Broadcast (ff: ff: ffs ff; ff: ff) 
(9 Address Resolution Protocol (request) 

Hardware type: Ethernet (1) 

Protocol type; IP (0x0800) 

Hardware size; 6 

Protocol size; 4 

Opcode; request (1) 

Sender MAC address: 4a:74\Ge:ba:d0;64 (4a; 74;6e:ba: d0; 64) 

Gondor 1) addeace: 179 9A 1A 1179 WW VAN) 


(0000 ff ff ff FF TF FF da 74 60 ba dO 6408 060001 ..,.., Jtnd. 
(0010 08 00 06 04 00 OL 4a 74 Ge ba dO 64 ac 14 0001 ass Jtmds 
(0020 0000.00 000000 1196 Pf de 


OW Wi-Fi enl: <live capture in... {Packets: 689 Displayed: 689 (100.0%) 4 Profile: Default 


Stopping capture 


— 


<€ 


bee 


6. Now, the last step is to save the capture file for 
later use. 

7. Save your file with the default.pcapng extension in 
your folder. 


If you have read all the steps all the way up to this 
point, I would encourage you to create your first 
capture file and save it in some workspace of your 
choice. 


Summary 


This chapter laid the foundation of basic networking 
concepts and gave an introduction to the Wireshark 
GUI. Wireshark is a protocol analyzer that is used 
worldwide by IT professionals to capture and analyze 
network-level packets. 


The Wireshark GUI is user-friendly, robust, and 
platform-independent; even new IT professionals can 
easily adopt the tool. 


One important aspect of protocol analyzing is to place 
the sniffer at the right place; every organization's 
infrastructure is different, so we might need 

to apply different techniques in order to get the right 
packets to use. 


Hubbing out, port mirroring, ARP poisoning, and 
tapping are some of those useful techniques that can 
be used to monitor and analyze traffic in different 
situations. 


There are six main parts in the Wireshark tool window: 
Menu Bar, Main Tool Bar, Packet List Pane, Packet 
Details Pane, Bytes Pane, and Status Bar. 


Using the back/forward key during a packet analysis 
scenario can be really useful. You should know about 
all the tools that are displayed in the main toolbar 
area. 





Filtering Our Way in 
Wireshark 


This chapter will assist you in identifying and applying 
the usage of Wireshark filters—namely, the capture 
and display filters. Filtering provides a powerful way to 
capture or see traffic; it is an effective way to 
segregate the desired traffic stream from noise (traffic 
). The following are the topics we will cover in this 
chapter: 


e Introducing capture filters 

e Why and how to use capture filters 
e Introducing display filters 

e Why and how to use display filters 


e Colorizing traffic 


Let's start our analyzer and apply some filters to 
understand the usage and effectiveness of them. We 
will take a step-by-step walk through the process of 
creating display and capture filters. Also, we will find 
utility, which is quite effective when troubleshooting 
network issues. 


Introducing filters 


The two types of filters offered by Wireshark are 
capture filter and display filter, which can be used over 
live traffic and/or with saved capture files. Filters 
provide advanced capabilities in performing packet 
analysis, where a user is able to separate the 
unwanted stream of packets from the stream of 
packets for analysis. 


Capture filters 


Capture filters enable you to capture only traffic that 
you want to be captured, eliminating an unwanted 
stream of packets. Capturing packets is a processor- 
intensive task, and packet analyzers use a good 
amount of primary memory while they are running. 


Packets are only sent to the capture engine if they 
meet a certain criterion (capture filter expressions). 
Capture filters do not facilitate advanced filtering 
options, as in display filters. 


The following is a screenshot of the Capture Options 
window dialog: 


Wireshark « Capture Interfaces 


Input Output — Options 


Interface Traffic Link-layer Header Promis« Snaplen (| Buffe 












nn \a_v. Ethernet default 
> vboxnetd La Ethernet ¥ default 2 
> vmnetl AULA. Ethernet ¥ default 2 
> vmnet® nL Ethernet ¥ default 2 
> vmnetlo rn Ethernet ¥ default 2 
any aaanrouWaaan Linux cooked ¥ default 2 
> Loopback: lo I __ Ethernet v default 2 
bluetoothd ___ Bluetooth HCI UART transport layer plus pseudo-header ¥ default 2 
nflog Linux netfilter log messages Y default 2 
nfqueue Raw IPv4 Y default 2 
usbmonl COT +1 v default 2 
usbmon2 COT +1 Y default 2 
Cisco remote capture: cisco ___ Remote capture dependent DLT 
Random packet generator: randpkt =... Generator dependent DLT 
SSH remote capture: ssh ___ Remote capture dependent DLT 
UDP Listener remote capture: udpdump Exported PDUs 
( ) 
V Enable promiscuous mode on all interfaces Manage Interfaces... 
Capture filter for selected interfaces: | |Enter a capture filter Compile BPFs 











Close Help 


The Capture Options dialog 


Let's take a walk through the options available in the 
Capture dialog window: 


e Capture (under input tab): Its purpose is to 
choose which interface you wish to listen on; 
multiple interfaces can also be selected to run in 
parallel. The details for every interface are listed 
under separate columns, such as Capture, 
Interface, the name of the interface, whether 
the promiscuous mode is enabled or not, and so 


on. Under the Capture dialog, you will see a 
checkbox to toggle the promiscuous mode, 
which enables you to listen to traffic that is not 
generated from or headed to your machine. 


Manage Interfaces: Facilitates addition or 
removal of a new interface for listening 
purposes. You can add even remote machine 
interfaces to listen remotely. 


Capture Filter: Lists capture filters and also 
facilitates the addition of new user-defined 
filters: 


SS == ti“ ( mC 


Manage Capture Filters 


Input Output — Options 
Ethernet address 00:00:5¢:00:53:00: ether host 00:00:5¢:00:53;00 


interface Ethernet type Ox0806 (ARP): ether proto 0x0806 a 
> vboxnet0) No Broadcast and no Multicast: not broadcast and not multicast 
> vmnetl No ARP: not arp 
> vmnet8 hei 
> vmnetlo [Pvd ony: ip 

any IPv4 address 192.0,2.1: host 192.0,2.1 
> Loopback: lo . 

bluetootho [Pv6 onl: p6 

nflog IPv6 address 2001:db8::1; host 2001:db8::) 

nfqueue 

usbmon} IPX only: ipx 

usbmon2 TCP only: tep 


Cisco remote capture: cisco 
Random packet generator: randpk UDP only: udp 


SSH remote capture: ssh TCP or UDP port 80 (HTTP): port 80 


UDP Listener remote capture: udp 
, HTTP TCP port (80): tcp port http 
No ARP and no DNS: not arp and port not 53 
Non-HTTP and non-SMTP to/from www.wireshark.org: not port 80 and not port 25 and host www... 


Capture filter for selected interfaces: | Enter a capture fite *| Compile BPFs 


¥ Enable promiscuous mode on all in 

















Start Close Help 


Default Capture Filters 
The Berkley Packet Filtering (BPF) syntax is an 
industry standard used for designing filters 
expressions and is supported by protocol analyzers 
such as tcpdump, Which makes a filter's configuration file 
portable. 


Wireshark - Capture Filters 


Name Filter = 
Ethernet address 00:00:5e:00:53:00 ether host 00:00:5e:00:53:00 

Ethernet type 0x0806 (ARP) ether proto 0x0806 

No Broadcast and no Multicast not broadcast and not multicast 

No ARP not arp 

IPv4 only ip 

IPv4 address 192.0.2.1 host 192.0.2.1 

IPv6 only ip6 

IPv6 address 2001:db8::1 host 2001:db8::1 

IPX only ipx 

TCP only tcp 

UDP only udp 

TCP or UDP port 80 (HTTP) port 80 b/ 
4 > 
+//-| 


Cancel Help 


The following are the steps to create your first capture 
filters expression; consider a scenario where you have 
to capture packets originating from a web server that 

is located at 10.10.10.157: 


1. Open the Capture Options dialog. 

2. Click on Capture Filter. 

3. Click on New. 

4. Write Fittering Host inside the Filter name textbox. 


5. Write host 10.10.10.157 inside the Filter String 
textbox: 


Input Output Options 











Interface Wireshark « Capture Filters Promis« Snaplen (| Buffe 
> vboxnetd t] default 2 
Name Filter = 
> vmnetl v default 2 
» vane ra "eel 1 defaut 2 
f. 
P vmnetlO pve adress 2001:cb8:1 host 2001:db8:1 yee 
any PX on ie Y default 2 
> Loopback: lo 1? a : ¥ default 2 
bluetoothd y p ‘¥ default 2 
nflog UDP ony udp ¥ default 2 
TCP or UDP port 80 (HTTP) port 80 ; 
nfqueue Y default 2 
HTTP TCP port (80) tcp port http P 
usbmonl Ys default 2 
ushmon? No ARP and no DNS . not arp and port not 53 LTE) defaut 2 
( Non-HTTP and non-SMTP to/from www,wireshark.org not port 80 and not port 25 and host www. Wi 
5c0 remote cq Filtering Host 
Random packet "™* 7 
SSH remote cap | ) 
UDP Listener re} 
( j +/|-||% , ) 
¥ Enable promiscu Ok Cancel Help Manage Interfaces... 
Capture filter for selected interfaces: | |Enter a capture fitter ’ Compile BPFs 





Close Help 


Creating a sample capture filter 


6. Once done, click on OK; if you've entered 
everything correctly (mostly the filter 
expression), the textbox followed by the Capture 
Filter button will be displayed with a green 
background. 

7. Capture Files (under output tab): Use this 
option to append stream of packets to an 
existing trace file. The captured packets will be 
added to the file of your choice. If you haven't 


chosen any, a temporary file will be created. For 
more advanced way of saving packets to 
single/multiple files, try the following: 


1. Create a new file automatically after: 
After capturing a certain amount of data 
(KB, MB or GB), Wireshark will create a 
new file to save a stream of packets. For 
instance, I want to create a new file after 
Wireshark captures 2 MBs of data. 


2. Next File Every (time): After a certain 
amount of time (seconds, minutes, or 
hours), Wireshark will create a new file to 
save a stream of packets. For instance, I 
want to create a new file every five 
minutes. 


3. Ring buffer: Use this option to set a limit 
for creation of new files based on the 
previously mentioned criteria. For 
example, you have selected the Ring 
buffer option and set the number of files 
tos, and you have configured that after 
every 5 MB, a new file should be created. 


According to this configuration, after every 5 MBs of 
data, a new file will be created and the packets will be 
written to it. Once the limit that you specified in the 
Ring Buffer is met, Wireshark will not create a new 


file; instead, it will start saving to the first file and 
append all captured packets to it. The following 
screenshot shows a similar kind of configuration: 


Wireshark « Capture Interfaces 


Input Output Options 


Display Options Name Resolution 
¥ Update list of packets in real-time ¥ Resolve MAC Addresses 
¥ Automatically scroll during live capture Resolve network names 
¥ Show extra capture information dialog Resolve transport names 


Stop capture automatically after... 


1 * packets 

1 * files 

1 *' kilobytes 
l * seconds ¥ 


Close Help 


The Capture Files option 


e Stop Capture Settings (options tab): This option 
lets you stop the capturing process after a 
certain condition is triggered; we have four 
different kinds of triggers. They are stated as 
follows: 


e Packet(s): Stop capturing after a certain 
count of packets is reached 


e File(s): Stop capturing after the creation 
of a certain number of files 


e Kilobytes(s): Stop capturing after 
capturing a certain amount of data 


e Seconds(s): Stop capturing after running 
for a certain period 


What if we select more than one option at a time, as 
shown in the following screenshot: 


Stop capture automatically after... 


1 *| packets 

1 * | files 

1 *| | kilobytes + 
1 *||\seconds + 


The Stop Capture options 


You can activate more than one option at a time; 
Wireshark will stop capturing whichever condition is 
met first. 


e Name Resolution (options tab): If selected, 
this feature can resolve the Layer 2, 3, and 4 
addresses to their corresponding names: 


Name Resolution 


¥| Resolve MAC Addresses 
Resolve network names 


Resolve transport names 


Name Resolution 


e Display Options (options tab): Use this option 
to customize how stream of packets and related 
information will be show in the Packet List Pane 
and the Protocol hierarchy window. Refer to the 
following screenshot: 


Display Options 
v Update list of packets in real-time 
¥ Automatically scroll during live capture 


¥ Show extra capture information dialog 


Display Options 


e Update list of packets in real-time: Packet 
List Pane is updated instantly as soon as a new 
packet is captured, and the pane will scroll 
automatically to display the most recent packets 


Why use capture filters 


Capturing only traffic that meets a criterion is 
required when a large volume of packets is flowing in 
network. Creating custom capture filters can come in 
handy for analyzing a root cause our while 
troubleshooting network issues. Wireshark discard 
packets that do not meet the capture filter expression 
and dropped packets will not be passed to the 
Capturing engine. 


How to use capture 
filters 


Use the Berkley Packet Filter (BPF) syntax to create 
capture filters through capture filter dialog. 


BPF is a combination of two arguments: identifiers and 
qualifiers, which are explained as follows: 


e Identifiers: Search criteria is your identifier. 
For example, capture filter like host 192.168.1.1, 
where the value 192.168.1.1 is an identifier. 


e Qualifiers: These are categorized into further 
three sections: 


e Type: There are three types of type 
qualifiers: host, port, and net. A type qualifier 
refers to the name or the number that 
your identifier refers to, e.g. in your 
capture filter host 192.168.1.1, host is the type 
qualifier. 


e Direction: Sometimes, when you need to 
capture packets from a source or 
destination, specify direction qualifiers 
along. For example, in the src host 192.168.1.1 


capture filter, src specifies to capture 
packets originating from 192.168.1.1. 
Likewise, if you specify dst host 192.168.1.1, 
would capture packets only destined to 


host192.168.1.1. 


e Proto: This qualifier is for filtering 
packets pertaining to a specific protocol. 
For example, if you want to capture nttp 
traffic coming from host 192.168.1.1, then 
expression Will be src host 192.168.1.1 and tcp port 


80 


e Wireshark support usage of and or operators to 
concatenate more than one expressions refer to 
following examples: 


e Filter src host 192.168.1.1 and tcp port 80 States that 
all the packets originating from 192.168.1.1 
and going to port so should only be 
captured. 


e Filter src host 192.168.1.1 or tcp port 80, States that 
every packet originating from 192.168.1.1 Or 
any packet associated with port so should 
only be captured. 


e Filter not port so States that any packet 
associated with port so should not be 





An example capture 


filter 


To access the default filters, go to Capture | Capture 
Filers or click on the Capture Options button in the 
main toolbar and click on Capture Filter. 


Refer to the following table for sample capture filters: 


Filters 
host 192.168.1.1 


port soso 


src host 
192.168.1.1 


dst host 
192.168.1.1 


src port 53 
dst port 21 
SiGe O27 168 ale, 
and tcp port 


2m 


dst 192.168.1.1 


Description 


All traffic associated with host 
192-168h ie 


All traffic associated with port soso 


All traffic originating from host 
192-168) 01 


All traffic destined to host 192.168.1.1 


All traffic originating from port s3 
All traffic destined to port 21 

All traffic originating from 
192.168.1.1 and associated with port 


Zi 


All traffic destined to 192.168.1.1 or 


OY dst 192.168.1.2 


not port so 


not src host 
192.168.1.1 


not port 21 
and not port 
22 


tcp 


Ipv6 

tcp or udp 
host www.google.c 
ether host 


07: 34: AA: B6: 78: 89 


destined to 
host 192.168.1.2 


All traffic not associated with port 
80 


All traffic not originating from 
host 192.168.1.1 


All traffic not associated with port 
21 Or port 22 


All tcp traffic 


All ipv6 traffic 

All TCP or UDP traffic 

All traffic to and from Google's IP 
address 

All traffic associated with the 
specified MAC address 


Display filters 


Display filters are flexible and powerful when 
compared to capture filters. Display filters do not 
discard any packets; instead, the packets are hidden. 
Discarding packets is not a very effective practice 
because, once the packets are dropped, they cannot be 
recovered. Applying a display filter will limit the 
packets to be displayed in the list pane of Wireshark. 


A display filter can be used for a capture file and live 
traffic in the Filter dialog box located above the Packet 
List Pane. Display filters support variety of arguments 
such as IP port, protocol, and so on. 


Let's learn how to use the display filter expression 
dialog for creating filters. 





[Mi [Apply a display filter ... <Ctri-/> 3 ~) Expression... + 





The filter expression 


1. Click on the Expression button to configure a 
display filter 


Wireshark + Display Filter Expression 


Field Name Relation 


> l0dapci IEC 60870-5-104-Apci 4 is present 
> 10dasdu IEC 60870-5-104-Asdu ss 
29West : 29West Protocol 


» dparityfec « Pro-MPEG Code of Practice #3 release 2 FEC Protocol > 

» 3COMXNS « 3Com XNS Encapsulation < 

> 3GPP2 All : 3GPP2 All >= 

> GLOWPAN : IPv6 over Low power Wireless Personal Area Networks <= 

> 802,11 Radio «802.11 radio information contains 
» 802.11 Radiotap « IEEE 802.11 Radiotap Capture header matches 
» 802,11 RSNA EAPOL : IEEE 802.11 RSNA EAPOL key in 


» 802.3 Slow protocols : Slow Protocols 


» 9? Pan 9 __. | Select a field to start building a display filter. 
> A-bis OML: GSM A-bis 0! 


» A21 + A21 Protocol 
) AF: AVTP Audio Format 
ALL: ATM ALL 
AAL3/4« ATM AAL3/4 
> AARP Appletalk Address Resolution Protocol 
> ASP Aastra Signalling Protocol 
» ACAP Application Configuration Access Protocol 
» ACN Architecture for Control Networks Value 
> ACP133 + ACP133 Attribute Syntaxes 
» ACR 122: Advanced Card Systems ACR122 : 
» ACSE SO 8650-1 OSI Association Control Service Predefined Values 
» ACtrace » AudioCodes Trunk Trace 
» ADB Android Debug Bridge 
» ADB CS: Android Debug Bridge Client-Server 
> ADB Service « Android Debug Bridge Service 
» ADP Aruba Discovery Protocol 
> ADwin ADwin communication protocol 
> ADwin-Config « ADwin configuration protocol 
» Aeron: Aeron Protocol 
» AFP Apple Filing Protocol 
> AFS (RX) - Andrew File System (AFS) 
> Agent « AgentX 
» AH. Authentication Header 
> AIM AOL Instant Messenger 
> AIM Administration - AIM Administrative 
AIM Advertisements AIM Advertisements 
» AIM BOS: AIM Privacy Management Service 
> AIM Buddylist AIM Buddylist Service 
> AIM Chat « AIM Chat Service 
AIM ChatNav « AIM Chat Navigation 
AIM Directory « AIM Directory Search 
AIM Email : AIM E-mail 
» AIM Generic - AIM Generic Service 
> AIM ICQ: AIM ICQ 
AIM Invitation » AIM Invitation Service 
» AIM Location « AIM Location 
» AIM Messaging : AIM Messaging 
AIM Popup « AIM Popup 
> AIM Signon « AIM Signon 
> AIM SSI AIM Server Side Info 
» AIM SST AIM Server Side Themes 
AIM Stats « AIM Statistics 
AIM Translate « AIM Translate 
» AIM User Lookup « AIM User Lookup 


> AJP13 « Apache |Serv Protocol v1.3 
ry pa nareiana ate Codina Mé Range (offset:length) 


Search: 
No display filte 


Ahint. 


Cancel Help 


2. For example, if you want to see only packets 
associated with ip: 192.168.1.1, then scroll down in 
the Field Name to find IPv4. Then, expand the 
section and choose the ip.addr option. 

3. From the Relation box next to it, choose the 
operator you wish to add in your expression. 

4. At last, write the IP you or in the Value (IPv4 
address) box and click OK 


Comparison and logical operators comes handy when 
creating filters complex filters. 


The following table lists the comparison operators that 
can be used to create filters: 


Operator Description 


==/eq Equal to 

!=/ne Not equal to 

</It Less than 

<=/le Less than equal to 
>/gt Greater than 


>=/ge Greater than equal to 


Following is the list of logical operators that are used 
to combine more than one criterion together. The 
following table lists all of them: 


Operator Description 


AND/& 


OR/| | 


NOT/! 


The AND logical operator is used 
when we want both parts of the 
expression to state true. For example, 
the ip.src==192.168.1.1 and tcp filters would 
only display packets originated from 
ip 192.168.1.1 and associated with the tcp 
protocol. 


The OR logical operator is used when 
we focus on one condition to be true 
at a time; For example, the port 53 or 
port so filters would display all packets 
associated with port 53 (ons) along 
with all packets associated with port 
80 (http) if any. 


The NOT logical operator is used 
when we want to exclude some 
packets from the list pane. For 
example, the: ans filter would hide all 
the packets associated with the DNS 
protocol. 


Retaining filters for 
later use 


Retaining filters saves time and effort required to type 
complex display filters. Wireshark facilitates retaining 
through saving custom filters. To create one for 
yourself, following are the steps: 


1. Go to Analyze | Display filters: 


Wireshark - Display Filters 





Name Filter = 
Ethernet address 00:00:5¢:00:53:00 eth.addr == 00:00:5¢:00:53:00 

Ethernet type 0x0806 (ARP) eth type == 0x0806 

Ethernet broadcast eth.addr == ffi tttettt 

No ARP hot arp 

IPv4 only ip 

IPv4 address 192.0.2.1 ip.addr == 192.0.2.1 

IPv4 address isn't 192.0.2.1 (don't use != for this!) 'ip.addr == 192.0.2.1) 

IPv6 only ipvé 

IPv6 address 2001:db8::1 ipv6.addr == 2001 :db8::1 

IPX only IDX 

TCP only tep 

UDP only udp 7 
4 b 
+/|-||% 


Cancel Help 


Adding Display Filters 


2. Click on New (+), enter the values in the Filter 
name and Filter string fields. For instance, we 
want to create a display filter for no are packets. 
Then, the values will look like the following 
screenshot: 


Wireshark « Display Filters 





Name Filter = 
IPv6 only ipvé 

IPv6 address 2001:db8::1 ipv6.addr == 2001 :db8::1 

IPX only IDX 

TCP only tep 

UDP only udp 

Non-DNS \(udp.port == 53 || tcp.port == 53) 

TCP or UDP port is 80 (HTTP) tep.port == 80 || udp.port == 80 

HTTP htt 

No ARP and no DNS not arp and !(udp.port == 53) 


Non-HTTP and non-SMTP to/from 192.0.2.1 ip.addr == 192.0.2.1 and not tcp.port in {80 2 






Cancel Help 


Creating a new filter 


3. Click on Apply. Now, your recently created filter 
will be listed at the bottom of list, which can be 
used later. 

4. Make sure that the Filter String box is shown 
with a green background, which means that 


your expression is correct; if it is in red color, 
then something is wrong, and if it is in yellow, 
this denotes that the results can be unexpected. 
. Click on the Expression button next to the Filter 
string box, to create filters through click and 
selecting what you require. 

. The Delete (-) button will delete an existing filter 
from the list. 

. The Cancel button will discard any unsaved 
changes and close the window. 

. The Ok button commits Save and closes the 
window. 


Searching for packets 
using the Find dialog 


For searching packets that meets a criterion use the 
Find tool bar adjacent to display filter. You can access 
the Find utility by navigating to Edit | Find packets or 
using the shortcut Ctrl+ F: 


Packet list Narrow & Wide y __ Case sensitive String ’ '10.10.10.157 
The Find Packet dialog 


You can also use the following filters for finding 
packets: 


Display filter v [arp 


Let's see some more configurable options available: 


e The display filter: Find packets based on specific 
IP /Port/ Protocol, for example: 
© ip.addr == 192.168.1.1 (based on an IP address) 
e port soso (based on a port number) 


e http (based on a protocol) 


e The Hex value: If you have the hex value fora 
packet, then use this option. For example, write 


in the physical address separated by colons, for 
example: 


© OA C4: 22: 90: 45: 00 


© AA BB: CC 


String: Enter the name of the DNS server, name 
of the machine, and any name that you are 
looking for (enter any string or word), for 
example: 


e Cisco 
e An administrator 
e A web server 


e Google 


Search In: Through this you can search in 
specific pane of Wireshark. For instance, if you 
are looking for a packet which matches the 
value Google (the ASCII value in the packet 
bytes pane will be matched). So, first choose the 
String option and then choose the Packet bytes 
from the first drop down. 


String Options: To enable and use this option, 
first select the String option and then select 





Colorize traffic 


For better and convenient viewing experience 
colorization of traffic is done to distinguish between 
different stream of packets. Colorization helps in 
differentiating between similar looking packets in 
ease. 


To access the default colorizing profiles navigate to 
View | Coloring rules as shown in the following 
screenshot: 


Wireshark «Coloring Rules Default 





Name Filter 


V SMB sm |] nbss | nbn | nipx | ipxsap | netbios 

v HTP http | tep pot == 80 | htp2 

1 PK ipk|| sp 

¥ DCERPC 

¥ Routing Arp | eigp | spf bgp |] cd | vrp carp qv gmp | ismp 
¥ TCPSYNFIN tepflags & Ox02 | tep.Aags.in == 1 

110 te 

v UDP udp 





( ) 
Double click to eal Drag to move. Rules are processed in order until a match is found. 


t= 


OK | Cancel | Import... Export... |Help 


Coloring rules 


All rules that are currently saved as part of your global 
configuration file to colorize traffic are listed in this 
dialog. Every packet listed in the packet list pane 
follows the rules defined in Coloring rules windows, 
which gives them a distinctive look. 


Let's use this feature and color the http error packets 
with a color combination of our choice. Say, for 
instance, a web server is configured and up and 
running file sharing purpose. Now, a client is trying to 
do directory listing and gets itp 404 error messages. 
These error messages are shown in the packet list 
pane and colored using the default nttp coloring rule 
that makes these errors less visible to us. To identify 


such packets quickly, colorize the utp 404 error 
messages with a black background and with a cyan 
foreground. Follow the steps to configure the same. 


1. Linux box is the client configured on IP 
172.16.136.129, and Macintosh running on 172.16.136.1 
that is configured as a web server: 


eee & Kali-Linux-1.0.9-vm-486 
il s& A ~ 4 oO 


Applications Places & GE) sat Jul18,01:17 © & r D)) 





XAMPP for OS X 5.5.24-0 - Iceweasel 





Iceweasel | [5] XAMPP for OS X 5.5.24-0 | 9 | 
@ | @ 172.16.136.1/xampp/ V@| [Bry coge a Gv 4 & 
fiMost Visitedy ®Exploit-DB {) Offensive Security|L.. {}ZeroBin » 


English / Deutsch a 


(=) XAMPP for Mac OS X 282" 


Portugués (Brasil) ; B= 





The web server running on 172.16.136.1 


2. Normal traffic from a Linux-accessing web 
server looks something shown as follows: 


No, | Time 


1 0,.000000000 

2 950618696, 077286000 
3 -2021440336, 836621000 
4 - 1898165200, 561362000 
5 41863044, 612094000 

6 0,001038000 

7 0,084997000 

8 0,085422000 

9 381882809, 99438000 
10 0, 106560000 

11 -1437096632, 910449000 
12 -950618696, 095408000 
13 - 136085583, 409139000 
14 -1321431987, 061550000 


Source 


172, 16, 136, 129 
172,16. 136.1 
172, 16, 136, 129 
172, 16, 136.1 
172, 16, 136, 129 
172,16, 136.1 
172, 16, 136.1 
172, 16, 136, 129 
172,16, 136, 129 
172, 16, 136.1 
172, 16, 136, 129 
172, 16, 136.1 
172, 16, 136, 129 
172, 16, 136.1 


Destination 


172, 16, 136.1 
172.16. 136, 129 
172, 16, 136.1 
172, 16, 136, 129 
172, 16, 136.1 
172.16, 136, 129 
172, 16, 136, 129 
172, 16, 136.1 
172, 16, 136.1 
172, 16, 136, 129 
172, 16, 136.1 
172.16, 136, 129 
172, 16, 136.1 
172, 16, 136, 129 


Protocol} Length! Info 


TP 
TP 
TP 
TP 
HTTP 
TP 
HTTP 
TP 
HTTP 
TP 
TCP 
TP 
TP 
TP 


60 5658-80 [SYN] Seq=0 Win=2920 
6480-55658 (SYN, ACK] Seq=0 Ack 
52 55658-80 [ACK] Seq=1 Ack=1 Wi 
52 [TCP Window Update) 8055658 
355 GET /xampp/ HTTP/1. 1 
52 8055658 [ACK] Seq=l Ack=304 | 
940 HTTP/1.1 200 OK (text/html) 
52 5565-80 {ACK} Seq=304 Ack=88 
400 GET /xampp/head, php HTTP/1. 1 
52 80-5658 [ACK] Seq=889 Ack=65 
60 5659-80 [SYN] Seq=® Win=2920 
6480-55659 (SYN, ACK] Seq=O Ack 
52 55659-80 [ACK] Seq=l Ack=1 Wi 
52 [TCP Window Update) 80..55659 


3. Now that everything is up and running, we will 
try to do some directory listing manually from 
client machine, to generate utp 404 error 
messages. 





Applications Sat Jul 18, 01:25 0 0 ¥ us @ root 





Browse and run installed applications Iceweasel 


Iceweasel ¥ object not found! | oP | 


@ | @ 172.16.136.1 ¥ @) [By cooQ) By Y 4 





fjMost VisitedY Exploit-DB {| Offensive Security| L.. { !ZeroBin » 


Object not found! 


The requested URL was not found on this server. If you 
entered the URL manually please check your spelling 
and try again. 


If you think this 1s a server error, please contact the 
webmaster, 


Error 404 


? Object not found! - Ic... 





4. The traffic generated through this request is 
captured and can be seen in the following 
screenshot: 


No, Time Source Destination Protocol) Length Info 








92 675, 958501000 172, 16, 136,129 172. 16. 136.1 TCP 52 55667480 [ACK] Seqzl Ack=) 
93 -1278177470, 593326000 172,16, 136, 1 172, 16, 136, 129 TCP 52 [TCP Window Update) 80.556 
94 675, 958885000 172,16, 136, 129 172, 16,136, 1 HTTP 362 GET /xampp/abe, jpg HTTP/1, 
95 238258651, 845389000 172,16, 136.1 172. 16, 136, 129 Te 52 60-55667 [ACK] Seqzl Ack=3 
96 -456584943, 391379000 172,16, 136, 1 172, 16, 136, 129 Te 657 (TCP segnent of a reassem 
97 675, 981774000 172,16, 136.1 172, 16, 136, 129 TCP 483 [TCP segnent of a reassenb 
98 675, 981788000 172,16, 136, 1 172. 16, 136, 129 TCP 282 (TCP segnent of a reassem 
99 -511200557,945281000 172,16, 136.1 172, 16, 136, 129 Te 273 [TCP segnent of a reassem 
100 1437100881, 841330000 172, 16.136.1 172. 16, 136, 129 HTTP/XNL GO HTTP/1.1 404 Not Found 

101 + 1177513788, 717358000 172, 16, 136, 129 172. 16, 136.1 52 55067-80 (TACKY SeqealT Ack 
102 -1177513788, 717358000 172, 6, 136, 129 172,16, 136, 1 Te 52 5567-80 [ACK] Seq=31l Ack 
103 675, 982078000 172,16, 136, 129 172, 16, 136.1 TP 52 55667-80 {ACK} Seq=311 Ack 
104 + 1177513788.717358000 172, 16, 136, 129 172.16, 136.1 Te 52 55667480 [ACK] Seqz=31l Ack 








HTTP 404 Traffic 


We can see, in the preceding captured traffic, 
that the client requested the abc.jpg resource, 
which was not available; thus, the client received 
a 404 Not found error. 


5. We figured out easily because there is just one 
client requesting a single resource. Consider a 
production environment with thousands of 
clients. In such cases, coloring a specific set of 
packets with a different rule is a game changer. 

6. Navigate to Edit Coloring Rules | New (+). Type 
HTTP 404 in the Name box. 

7. TYPe€ http. response.code==404 in the Filter box. Choose 
the Foreground Color option as cyan, and choose 
the Background Color option as Black. Then, 
click on OK: 


Wireshark » Coloring Rules » Default 





sm |] nbss | nbs | nip | ipxsap || netbios 


V HTTP http | tep port == 80 | ttp2 

VX in || Spx 

¥ DCERPC dcerpe 

¥ Routing Arp ela | asp bap |} cd | vp | carp | gp | gm | ismp 
¥ TCPSYNFIN tep flags & Ox02 | tp.lags.in == 1 

VTC {tp 

V UDP udp 


( ) 
HITP 404: ‘hto.resp is nether a field nora protocol nae, 
t= 4 





Background 


Cancel | Import. Export... |) Help 


8. Click OK and you will see the new rule in action: 











No. | Time Source Destination Protocol] Length| Info 
94 675, 958885000 172.16. 136, 129 172.16, 136.1 HTTP 362 GET /xampp/abc. jpg HTTP/1.1 
95 238258651, 845389000 172, 16,136, 1 172, 16, 136, 129 TcP 52 80-55667 [ACK] Seq=l Ack=31 
96 -456584943, 391379000 = 172, 16, 136.1 172, 16,136, 129 T¢P 657 [TCP segment of a reassemble 
97 675, 981774000 172,16, 136,1 172,16, 136, 129 T¢P 483 [TCP segment of a reassenble 
98 675, 981788000 172.16, 136.1 172,16, 136, 129 TCP 282 [TCP segment of a reassemble 
99 -511200557,945281000 172, 16, 136.1 172,16, 136, 129 TcP 273 [TCP segment of a reassemble 

| __ 100 -1437100881.841330000 172.16.136.1 172,16. 136.129 HTTP/MLG.HTTP/I.1 404 Not Found | 
101 - 1177513788, 717358000 172. 16, 136. 129 172.16, 136.1 T¢P 52 55667+80 [ACK] Seq=311 Ack=¢ 
102 -1177513788, 717358000 172, 16, 136, 129 172,16, 136.1 TcP 52 5667-80 [ACK] Seq=311 Ack=) 
103 675, 982078000 172, 16.136, 129 172,16, 136.1 TCP 52 55667480 [ACK] Seq=311 Ack=] 
104 -1177513788, 717358000 172, 16, 136, 129 172, 16,136, 1 TcP 52 5567-80 [ACK] Seq=311 Ack=) 
105 - 1437162184, 138035000 172. 16, 136. 129 172,16, 136.1 TCP 52 55667-80 [ACK] Seq=311 Ack=) 


After applying the new coloring rule 


Coloring rules are applied to the packet list pane ina 
top-to-bottom manner. With every packet, there is 
coloring rule information attached that can be listed 
from Packet Details Pane under the Frame section, as 
shown as follows: 


No. | Time Source Destination Protocol] Length| Info 
100 - 1437100881, 841330000 172, 16, 136.1 172,16, 136, 129 HTTP/XML GO HTTP/1,1 404 Not Found 
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basaeas 


Vv Frame 100; 60 bytes on wire (480 bits), 60 bytes captured (480 bits) on interface 0 
Interface id: 0 (pktap0) 
Encapsulation type: Raw IP (7) 
Arrival Time: Jan 1, 1970 22:31:42.296705000 IST 
[Time shift for this packet: 0.000000000 seconds] 
Epoch Time; 61302, 296705000 seconds 
[Time delta from previous captured frame; -925900323, 896049000 seconds] 
[Time delta from previous displayed frame; -925900323, 896049000 seconds] 
[Time since reference or first frame; -1437100881, 841330000 seconds) 
Frame Number; 100 
Frame Length: 60 bytes (480 bits) 
Capture Length: 60 bytes (480 bits) 
[Frame is marked: False] 
[Frame is ignored: False] 
[Protocols in frame: raw:ip:tcp:http:data: data: data: data: data; data: data: data: data; data: data: data: data: data: data: data: data; data 
(Number of per-protocol-data: 1] 





| 


{Coloring Rule String: http. response, code==404] 


Coloring info in a frame header 


Create new Wireshark 
profiles 


Profiles are like customized virtual environments, 
which saves significant amount of time while 
auditing/troubleshooting a network. 


To create a profile, follow these steps: 


1. Right-click on the Profile column in Status Bar 
(bottom right corner of window): 


Profile: Default 


2. Click on + in the pop-up dialog: 


Wireshark « Configuration Profiles 





Default 
Bluetooth 
Classic 
New profile 


+/|-||% Created from default settings 


Cancel Help 


3. Now, choose any profile you wish to use as a 
template (if any) and type the name of the new 
profile. 

4. And then, click on OK. 


Now, in the status bar, you will see the new profile has 
been activated. The changes that you will make in this 
profile stays here, for example, you create 
capture/display filters, change protocol preferences, 
and change color preferences, and so on. 


Profile: New profile 


Also, importing and exporting profiles is easy just copy 
and paste the Profile configuration files in a Wireshark 
directory to use. 


Summary 


Filtering traffic lets you capture and see only stream of 
packets you want; there are two types of filters: 
display filters and capture filters. 


Display filters hide the packets; however, capture 
filters discard the packets that do not meet user 
defined expression and discarded packets are not 
passed to the capturing engine. 


Capture filters use the BPF syntax, which is an 
industry standard and is used by several other 
protocol analyzers. 


Find utility is useful and can be accessed from the Edit 
menu in Wireshark. The Find utility gives various 
vectors to search a packet(s) and related details. 


Coloring preferences comes handy when filtering a set 
of traffic. Distinguishing packets becomes easy, as the 
matched packets will be displayed with a unique 
coloring scheme. 


Profiles are like virtual scenarios that saves time and 
efforts. Changes made to a profile with respect to 
display/capture filter and color/protocol/time 
preferences, stays within the same. 


Analyzing Application 
Layer Protocols 


This chapter will help you understand the approach 
and methodology for analyzing application layer 
protocols such as HTTP, SMTP FTP, and DNS through 
Wireshark. Application layer protocols typically 
interfaces between a client and server. 


It is critical to understand the structure of application 
layer protocol packets in order to identify anomalies 
efficienctly. We will be discussing the following topics 
in detail throughout this lesson: 


e Analysis of common application layer protocols 
e Assembling VoIP packets 


e Decrypting encrypted traffic 


Domain Name System 
(DNS) 


Imagine a world of internet where you have to type a 
random numerical value 

(IP address) in your web browser's address bar, 
instead of a name, to visit a website. Also, imagine that 
each numerical figure is different. Considering this, 
how many numbers (IP addresses) can you memorize? 
5? 10? Perhap, 50 at max? So, now, you are confined to 
visiting just 50 websites. 


For the sake of a limitless web experience, DNS comes 
to our rescue. DNS stores a dataset (zone file) of 
website names mapped to their current IP addresses, 
along with the names of the domains. Each entry in the 
zone file is termed a resource record (combination of 
website name and its IP). DNS uses TCP and UDP, both 
for different purposes, over the port 53 by default. 


How does DNS work? So, as a client, when you try to 
visit a website from a browser, your request (DNS 
query) is sent to an internal DNS server (if any) that 
looks up the resource records it contains. If the DNS 
server knows the IP address for the domain you are 
trying to visit, your PC will get a reply (DNS response) 
containing the IP address of the website you desire to 
visit, else your query will be forwarded to external 
DNS servers on the web (for example, google DNS 
servers at 8.8.8.8, 4.4.2.2, and SO On.). 





Dissecting a DNS packet 


A DNS packet consists of multiple fields that are briefly 
discussed here: 


e Transaction ID: This is a number that keeps 
track of a domain query and it's corresponding 
response. 


e Query/response: Every DNS packet is marked 
as a query or a response. 


e Flag bits: Each query and response contains a 
different set of flag bits, which are as follows: 


e Response: The message is a query ora 
response. 


e Opcode: This determines the type of 
query contained. The Opcode ranges 
between 0-15. Refer to the following table: 


0 1 2 3 4 


Server 


Standard | Inverse status Unassigned Notify 
query query eaest 


0 


No 


error error failure error implemented 


1 


Truncated: This determines whether the 
packet is truncated if its size is large 
(greater than 512 bytes). 


Recursion desired: The query sent by 
your client is supposed to go ona 
recursive search procedure from one 
DNS server to another if the resource 
record you are looking for is not present 
in the primary DNS. 


Recursion available: If this bit is set, 
then it means the recursion that your 
client requested is available. 


Reserved (z): As defined by RFC 1035; 
reserved for future use, must be set to 
zero for all queries and responses. 


Response code: The values in this field 
signifies the response. This field is used to 
signify whether there are errors and the 
types of errors. Here are the possible 
code values that you can receive: 


2 3 4 5 


Format Server Name Not 


Re 


e Questions: Number of queries present in the 
packet. 


e Answers: Number of answers sent in response 
to the query. 


e Authority RRs: Number of authority resource 
records sent as response. 


e Additional RRs: Number of additional 
resource records sent as response. 


Query section: The query sent to the DNS 
server; it should be the same in the response 
received. 


Answer section: Answer consists of the 


resource records that came in as response. 


Type: Type of query sent. Refer to the following 
table for common query types: 


A NA MX SOA PTR A 
Host Name Mail Start of Pointer | I 
zone 


address server exchange record a 


authority 





Dissecting DNS 
query/response 


Let's consider a scenario to understand the way DNS 
works. A client sends a query to a DNS server that 
possesses name resolution information. Using this 
information, the client can start IP-based 
communication. Sometimes, the information the client 
is looking for is not available with the DNS server it 
requested. In such cases, the DNS server itself 
transfers the query to any neighbor DNS it knows 
about, if recursion is desirable. Refer to the following 
screenshot, where a request is sent to Visit https: //ww.googl 
e.co.in. A request from a client located at 192.168.1.103 is 
sent to the default gateway at 192.168.1.1. This gateway 
will forward the query to a DNS server it knows about: 


b Frame 9: 74 bytes on wire (592 bits), 74 bytes captured (592 bits) on interface 0 
b Ethernet II, Src: Apple b9:53:ec (d8:bb:2c:b9:53:ec), Dst: Zte.07:73:6c (d0:5b:a8;07; 73; 6c) 
b Internet Protocol Version 4, Sre: 192, 168,1.103 (192.168, 1.103), Dst: 192,168.1.1 (192.168, 1.1) 
b User Datagram Protocol, Src Port: 65382 (65382), Dst Port: 53 (53) 
Vv 
[Response In; 10] 
Transaction ID; Ox2b4a 
> Flags: 0x0100 Standard query 
Questions: 1 
Answer RRs; 0 
Authority RRs: 6 
Additional RRs; 0 
¥ Queries 
V www. google.com: type A, class IN 
Name; www, google, com 
(Name Length: 14] 
[Label Count: 3] 
Type: A (Host Address) (1) 
Class: IN (0x0001) 


DNS query 


You may notice that DNS is using UDP as an 
underlying protocol. If you want to know more about 
the DNS query being generated, just expand the Flags 
section. This section will list various details, such as 
whether recursion is available, whether recursion is 
desired, and what the response code is. Please refer to 
the following screenshot: 


V Flags: 0x0100 Standard query 
Ses Bere anes aat) = Response: Message 1s a query 
000 0... sss. se. = Opcode; Standard query (0) 

0. sic. sess = Truncated: Message 1s not truncated 
tate 1... ss. = Recursion desired: Do query recursively 
vse Qee vee = Zi reserved (0) 

Ck tea HH 0..,., = Non-authenticated data: Unacceptable 


Expanded flags section 


The expanded Flags section tells us that the type of 
DNS packet is a query, the packet data is not 
truncated, and recursion is desirable if available. 


In response to this query, you will observe one packet 
with the same transaction ID that denotes the 
association of a DNS query sent by the client. The 
response for the query will usually consist of an IP 
address for the domain visited. The requesting 
machine will be returned a single IP or maybe multiple 
IPs available to it. If the domain we are looking for is 
not available, then it's probable CNAMEs will be 
returned in as favor. 


Refer to the following screenshot to understand this: 


b Frame 10: 154 bytes on wire (1232 bits), 154 bytes captured (1232 bits) on interface 0 
b Ethernet IZ, Src: Zte 07:73:6¢ (dO: 5b:a8:07:73:6c), Dst: Apple b9:53:ec (d8:bb: 2c:b9: 53: ec) 
b Internet Protocol Version 4, Src: 192,168.1,1 (192,168,1.1), Dst: 192,168,1,103 (192.168, 1, 103) 
b User Datagram Protocol, Src Port: 53 (53), Dst Port: 65382 (65382) 
v 
[Request In: 9] 
[Time: 0,004678000 seconds) 
Transaction ID; Ox2b4a 
b Flags: 0x8180 Standard query response, No error 
Questions: 1 
Answer RRs: 5 
Authority RRs; 0 
Additional RRs; 0 
> Queries 
¥ Answers 
b www.google.com: type A, class IN, addr 173,194, 36,84 
) www.google.com; type A, class IN, addr 173,194, 36,83 
b www, google, com; type A, class IN, addr 173,194, 36,82 
b www.google.com: type A, class IN, addr 173,194, 36,80 
) www.google.com: type A, class IN, addr 173,194, 36,81 


DNS response 


As I said, we could get multiple replies. If you notice 
the Answer RRs section, we have received five replies 
for the ww.google.con domain. For verification that the 
response received belongs to the previous query only, 
just match the Transaction ID. 


Expand any section in the Answers category to view 
more details. Refer to the following screenshot: 


Vv Answers 
v www.google.com: type A, class IN, addr 173.194, 36.84 

Name: www.google.com 
Type: A (Host Address) (1) 
Class: IN (0x0001) 
Time to live: 13 
Data length: 4 
Address: 173.194.36.84 (173.194.36.84) 


File transfer protocol 


Since the internet came into existence, we have been 
working with the file transfer protocol (FTP). FTP 
uses TCP over port 21 or 20 (by default) to initiate and 
transfer files over a designated channel. There are 
only two types channel command channel (port 21) and 
data channel (port 20). The command channel is used to 
send and receive the commands and their responses. 
The data channel is used to send and receive data 
between the client and the server. However, you will 
observe random port numbers used to transfer TCP 
data segments from your client machine. 


Dissecting FTP 
communication packets 


There are two types of mode a client can use to 
communicate with a server: active and passive. In 
earlier versions of FTP server applications, active 
mode was enabled by default, but in the latest versions 
of FTP server applications, passive mode is enabled by 
default. For understanding these modes in detail, let's 
use the following scenario. 


Let's say an FTP server is configured at IP 172.16.136.129 
and a client at IP 172.16.136.1. 


Typically, every request sent from the client is a 
specific command set, to which the server responds 
with a numerical value followed by a text message. See 
the following screenshot for reference followed by a 
short analysis: 


4 0,018723000 172,16,136,129 172, 16, 136.1 FIP 88 Response; 220 Welcome to Charit's FIP se 
5 555032032, 287455000 172,16, 136.1 172, 16. 136.129 TCP 52 56982-21 [ACK] Seq=1 Ack=37 Win=131728 L 
6 -952210303.718297000 172.16. 136.1 172.16, 136.129 FIP 62 Request: USER abc 

7 + 143593220, 746255000 = 172,16.136,129 172. 16. 136.1 TCP 52 2156982 [ACK] Seq=37 Ack=11 Win=29696 L 
8 4,629189000 172, 16,136,129 172,16, 136.1 FIP 86 Response: 331 Please specify the passwor 
9 4, 629206000 172, 16, 136,1 172,16. 136,129 TCP 52 56982-21 [ACK] Seq=ll Ack=71 Win=131696 
10 5, 732635000 172, 16, 136,1 172,16. 136.129 FIP 62 Request: PASS abc 

11 - 1086390884, 249094000 172,16.136.129 172.16, 136.1 FIP 75 Response: 230 Login successful, 

12 2070317539, 792672000 172,16, 136.1 172.16, 136.129 TCP 52 5698221 [ACK] Seq=21 Ack=94 Win=131672 





The server requested the password, which the client 
provided. Once the server receives and validates the 
password, the user will be logged in. In our case, the 


password is correct, so the client receives 230 aS a 
response code followed by a togin successful MeSSage. 


Commands issued from the client side can have 
arguments or no arguments, and the data transmitted 
between the devices can be seen in the TCP header of 
the packet, as shown here: 


43 -544276953, 032968000 172. 16, 136.1 172, 16,136,129 FIP 58 Request: LIST 


/O00 
VU 


46 894485615, 992662000 













172,16.136,129 172,16, 136.1 TCP 52 2057197 [ACK] Seq: 





47 894485615.992690000 172, 16, 136.1 172, 16,136,129 TCP 52 [TCP Window Update] 
48 -540049189, 689031000 172,16.136.129 172,16,136.1 — FIP 91 Response; 150 Here 
49 894485615.993039000 172. 16, 136,1 172,16,136,129 TCP 52 5719621 [ACK] Seq: 
K1 2AQAQEAD AQRGAAA =—-1'77:1h 13K 1 177 18 128.190 TEP 2 67107 90 [ACK] Gans 


4 


b Frame 50: 314 bytes on wire (2512 bits), 314 bytes captured (2512 bits) on interface 0 

b Raw packet data 

b Internet Protocol Version 4, Src: 172.16. 136.129 (172. 16.136.129), Dst: 172.16. 136.1 (172,16. 136, 1) 

b Transmission Control Protocol, Src Port: 20 (20), Dst Port: 57197 (57197), Seq: 1, Ack: 1, Len: 262 
FIP Data (drwxr-xr-x 2 1001  —-1002 4096 Aug 03 00:45 Desktop\r\n-rw-r--r-- 10 


FTP-data returned 


Frame 43 shows that the client issued the 1st command, 
which was processed by the server, and that 262 bytes 
of data was returned. FTP-based communication can 
be seen in plaintext through protocol analyzers, which 
is also a weakness often exploited. 


Reassembling the FTP data stream is easy because 
apart from the data, there is nothing that is 
transmitted. There is no code or command that gets 
appended to the packets. To reassemble the TCP 
stream of FTP packets, just right-click on the selected 
packet and choose the Follow TCP Stream option to 
view. 


Refer to the following screenshot: 


Wireshark « Follow TCP Stream (tcp.stream eq 2) + wireshark_lo_20180601105508 ... 





220 (vsFIPd 3.0.3) 

USER gpftp 

331 Please specify the password. 

PASS adminfi123 

230 Login successful. 

SYST 

215 UNIX Type: L8 

PORT 127,0,0,1,171, 213 

200 PORT command successful. Consider using PASV, 
LIST 

150 Here comes the directory listing. 

226 Directory send OK. 

PWD 

257 "/home/gpftp/ftphome" is the current directory 


Packet 455. 9 client pkts, 9 server pkts, 15 turns. Click to select. 


A 
¥ 


Find: Find Next | 


Filter Out This Stream Print Save as... Back 


Entire conversation (331 bytes) * Showandsavedataas ASC] = * Stream 2 


|| Close |) Help 


FTP stream 


The entire communication between the client and the 
server that happened over the data and command 
channels is translated into human-readable format. 
Text in red is what the client sent, and text in blue is 
what the client received. It is recommended to 

use secure versions of FTP in order to mitigate the 
vulnerability. 





Hypertext Transfer 
Protocol (HTTP) 


Data on the web is transferred using the HTTP/HTTPS 
application layer protocol. Normal communication in 
HTTP follows a request/response model, where the 
communication between a client and a server is 
coordinated by a set of rules. The client requests for a 
certain resource to the server and then receives a 
status code that specifies the current status of the 
requested resource. If available then, the resource is 
also sent along with the status code, else the client 
would receive a not-available status code. 


How request/response 
works 


Web servers utilize HTTP to serve web pages to the 
requesting clients. At the beginning of every HTTP 
session, the TCP three-way handshake takes place. It 
creates a dedicated channel between the 
communicating hosts followed by HTTP and data 
packets, which are sent in and received while the 
session is active. For instance, say you are visiting a 
web server located at nttp: //172.16.136.129 from a client at 
172.16.136.1. USing our client-server infrastructure, we 
will try to capture the requests sent and responses 
received. 


I will try to visit the home page located at the server 
mentioned earlier and will capture the traffic 
generated for the whole session; that is, the requests 
sent and responses received. Take the following steps 
to replicate the scenario. 


Request 


Following are the steps for the preceding scenario: 


1. Open your browser and type the Uniform 
Resource Locator (URL) of any website. 

2. The website is located at nttp: //172.16.132.129 (a local 
web server). Here is the screenshot for your 
reference: 


@ee < im 172.16.136.129 ¢ x >» [+ 


Charit's Web Server! 


This is the default web page for this server. 


The web server software is running but no content has been added, yet. 


3. The following screenshot depicts the packets 
captured as a result of visiting the web server: 


1 0, 000000000 


2 - 1438998251, 586830000 


3 0,000146000 


5 - 1439017790, 883535000 
6 548191280. 817750000 


7 0,070913000 
8 5.073679000 
9 5,073739000 
10 29, 999840000 
11 30.000161000 


172, 16, 136.1 
172, 16, 136, 129 
172, 16. 136.1 


172, 16, 136, 129 
172, 16, 136, 129 
172. 16. 136.1 
172. 16, 136,129 
172, 16, 136.1 
172, 16. 136.1 
172. 16, 136.129 


172, 16. 136.129 
172, 16. 136.1 
172, 16. 136. 129 


172, 16. 136.1 
172, 16. 136.1 
172, 16. 136. 129 
172,16. 136.1 
172, 16. 136, 129 
172, 16. 136. 129 
172, 16. 136.1 


TCP 
TCP 
TCP 


TCP 


HTTP 


TCP 
TCP 
TCP 
TCP 
TCP 


64 59781-80 [SYN] Seq=0 Win=65535 
60 80--59781 [SYN, ACK] Seq=0 Ack=1 


52 59781480 [ACK] Seq=l Ack=1 Win= 


52 80-59781 [ACK] Seq=l Ack=416 Wir 


262 HTTP/1,1 304 Not Modified 


52 59781-80 [ACK] Seq=416 Ack=211 \ 
52 80-59781 [FIN, ACK] Seq=211 Ack 
52 5978180 [ACK] Seq=416 Ack=212 \ 
52 59781-80 (FIN, ACK] Seq=416 Ack: 
5280-59781 [ACK] Seq=212 Ack=417 \ 


4. All these packets get generated as soon as you 
press Enter. As you can see, the first three 
packets are TCP three-way handshake packets 
where our client is requesting that the server 
creates a dedicated channel. However, if the 
server daemon wasn't running or the server 


wasn't accepting our requests, for some reason 
then we would have seen est a packets, like the 
one shown here: 


1 0,000000000 


172.16, 136.1 


172.16, 136,129 TCP 


64 59783-80 [SYN] Seq=O Win=f 





5. This error states that the server is out of service 
or is not supposed to respond to our requests 


(firewalled or restricted zone). 


6. After the TCP packets, the first HTTP request 
sent by our client is observed. Every request 
comprises a couple of elements that are sent to 
the server: 


Host: 172, 16,136, 129\r\n 

If-None-Match; "12625d-bc-51c6ab45063d1"\r\n 

Accept: text/html, application/xhtml+xml, application/xml; q=0.9, */*; q=0,8\r\n 
If-Modified-Since: Mon, 03 Aug 2015 16:31:40 GMT\r\n 

User-Agent: Mozilla/5.0 (Macintosh; Intel Mac 0S X 10.10 3) AppleWebKit/600, 6, 3 
Accept-Lanquage: en-us\r\n 

Accept-Encoding: gzip, deflate\r\n 

Connection; keep-alive\r\n 


HTTP request 


In the first line, there are three things 
passed on to the server as the arguments, 
which are the HTTP method, the 
requested resource, and the location 

/ (root directory). 


The tost argument is required by the 
HTTP/1.1 protocol requests. The value of 
this field is the web server's address that 
you typed in the address bar of the 
browser. 


The accept parameter specifies what kind of 
content is acceptable by the requesting 
client response. 


The 1f-modified-since parameter is sent from 
the client to the server, which includes the 
date and time of your previous request 
made to the server. If the server contents 


have been changed since your previous 
request, then you will receive the new 
updated page. Otherwise, your system 
will present you with the locally cached 
page. 


The user-agent specifies the browser- 
related information that you are using. 
This information is to be used by the 
server to present you with browser- 
compatible content. 


Parameters such as Accept-Language and 
Accept-Encoding are passed on to the 
server to inform us of what type of 
content is acceptable to the client. 


The Connection-alive parameter specifies 
whether the client wishes to keep the 
connection working after this particular 
request has been processed. 


Response 


1. After the fourth packet, the server 
acknowledges the client's request to get to the 
web server's root directory. The server starts 
transmitting the resource that the client 
requested. 

2. The sixth packet in the list pane is what the 
client received, a status code followed by a short 
message, including the content of the resource 
requested. Refer to the following screenshot 
illustrating the HTTP response: 





to 2. 1636.18 17.16.1381 ATP ISDA 30 ot fie 
7 1439018536, 131505000 172,16.136,1 — 172,16,136,129 TCP 52 59784480 [ACK] Seq=416 Ack=211 W 
8 5,010003000 172,16, 136,129 172.16,136.1 TCP 52 8059784 [FIN, ACK) Seq=211 Acke 
9 5,010052000 172.16,136.1 —172,16.136,129 TCP 52 5978480 [ACK] Seqr4l6 Ack=212 W 


10 + 1669050675, 223075000 172,16,136.1 172.16, 136.129 TCP 52 $9784.80 [FIN, ACK) Seq=416 Ack: 
V1 TORAAUGQTA WAAIAQANA 17718 13819017 RAAT TPP 57 WMSQ7RA AKT SanzI1? dek=d17 W 


Hypertext Transfer Protocol 





Date: Mon, 03 Aug 2015 17:32:35 GMT\r\n 

Server: Apache/2, 2.22 (Debian)\r\n 

Connection; Keep-ALive\r\n 

Keep-Alive: timeout=5, max=100\r\n 

Tag: *12625d-be-51c6ab45063d1"\r\n 

Vary: Accept-Encoding\r\n 

\r\n 

[HTTP response 1/1] 

[Time since request: 526547318, 508758000 seconds] 


[Request in frame; 4) 


HTTP response 


3. As a part of TCP communication, the client will 
acknowledge every packet sent by the server, as 
seen in the seventh packet. 

4. Let's dissect the response elements for packet 
number six: 


1. The first line consists of three arguments 
sent in response. They denote the HTTP 
protocol version in use, the status code 
(304 in our case, which specifies 


that the requested resource did not 
change since the time mentioned in 
the pate parameter), and finally, a brief 
description of the status code (not 
modified in our case). 


. In the third line, the Server parameter 
mentions the name and version of 

the web server. We can see that 
Apache/2.2.22 is the server that 

is located at 172.16.136.129. 


. The fourth and fifth lines state that the 
server wishes to keep the connection 
alive. The duration for which the server 
wishes to do so is also mentioned in the 
next line of the parameters. 


Simple Mail Transfer 
Protocol (SMTP) 


SMTP is used widely to send and receive emails over a 
small network. The protocol uses the Sender-SMTP 
process to send emails and the Receiver-SMTP process 
to receive emails. This makes SMTP a client-server- 
based protocol that runs over port 25. 


Typically, an SMTP channel for mail transfer is created 
through a successful TCP three-way handshake 
followed by a series of SMTP packets: 


= = 


—ee OO 
PC 2: SMTP 
Client 
(192.168.1.104) 








PC 1: SMTP 
Server 
(192.168.1.105) 


In our lab, we have an SMTP server configured at IP 
192.168.1.105 and a Client at IP 192.168.1.104. The client will 
request the server to sends an email to an address 
known to the client. The server will respond to this 
request with numerical code, followed by a brief 
response parameter. 


Dissecting SMTP 
communication packets 


Using the Netcat client from a Kali Linux machine, I 
will connect to the SMTP mail service running ona 
Windows machine. After a successful three-way 
handshake, the server will respond with numerical 
codes with a short summary. Follow these steps to the 
send an email using command line: 


1. Open a connection with the mail server using 
netcat nc -nv 192.168.1.105 25. 

2. Initialize an SMTP session with the teto testmait 
command. 

3. Specify the from address using the mar From 
<abc@charit . com> command. 

4. Specify the recipient's address using the rcets To: 
<efg@charit. com> command. 


5. To enter data into the mail body, type pata, press 
Enter, and type. (full-stop; this is a terminating 
character, and you can use any character of 
your choice) Now, type the message you wish to 
send. Once you are finished typing your mail, 


type a. (full stop) to mark the ending and press 
Enter. 


6. Now, your message will be sent. 


The process will generate a couple of packets that 
contain details about our session. All of these 
commands mentioned will only work when the server 
is configured to permit clear text message 
communication without any authentication; refer to 
the following screenshot: 


3 41448, 227586000 

4 4205130,997054000 

§ 1439081652, 143751000 
6 + 287363963, 384218000 
7 1744899513, 486830000 
§ 1439081657, 529807000 
9 1744901809, 636862000 
10 1744899513, 488830000 
11 1439081671, 468558000 
12 1439081686, 949708000 
13 4206566, 333758000 

14 1439081687, 064346000 
15 1439081688, 805525000 
16 4207044, 779326000 

17 2122359292, 356797000 
18 1439081690, 221834000 


20 1439081690, 454208000 


22 168258645, 511998000 
23 419451065, 438925000 
24 1439081690, 858935000 
25 168257924, 091710000 
26 1439081694, 129351000 


192, 168, 1, 104 
192, 168, 1, 105 
192, 168, 1, 104 
192, 168, 1, 104 
192, 168, 1, 105 
192, 168, 1, 104 
192, 168, 1, 104 
192, 168, 1, 105 
192, 168, 1, 104 
192, 168, 1, 104 
192, 168, 1, 105 
192, 168, 1, 104 
192, 168, 1, 104 
192, 168, 1, 105 
192, 168, 1, 104 
192, 168, 1, 104 


192, 168, 1, 105 


192, 168, 1, 104 
192, 168, 1, 05 
192, 168, 1, 104 
192, 168, 1, 104 
192, 168, 1, 105 


192, 168, 1, 105 
192, 168, 1, 104 
192, 168, 1. 105 
192, 168, 1, 105 
192, 168, 1, 104 
192, 168, 1, 105 
192, 168, 1, 105 
192, 168, 1, 104 
192, 168, 1. 105 
192, 168, 1, 105 
192, 168, 1, 104 
192, 168, 1, 105 
192, 168, 1, 105 
192, 168, 1, 104 
192, 168, 1. 105 
192, 168, 1, 105 


192, 168, 1. 104 


192, 168, 1, 105 
192, 168, 1, 104 
192, 168, 1, 105 
192, 168, 1, 105 
192, 168, 1, 104 


§2 5707325 (ACK) Seg) Ack=L Win=29696 Len: 
905; 220 Charit's, com ESNTP server ready, 
§2 57073425 [ACK] Seqzl Ack=39 Win=29696 Ler 
61 C: helo abe 

82; 250 Charit's.com Hello, abc, 

§2 57073425 (ACK) Seqzl0 Ack=69 Win=29696 Le 
79.C: mail from: <abc@charit, com 

815; 250 Sender OK » send RCPTS, 

§2 57073425 [ACK] Seq=37 Ack=98 Win=29696 L 
78.C; repts to: <efgécharit, com 

915; 250 Recipuent OK + send RCPT or DATA, 
§2 5707325 (ACK) Seqe63 Ack=137 Win=29696 | 
§7C; data 

915; 354 0K, send data, end with CRLF, CRLF 
§2 57073425 (ACK) Seq68 Ack=176 Win=29696 | 
§5(; DATA fragnent, 3 bytes 


§2 25457073 (ACK) Seqe)76 Ack=71 Win=16314 | 


§4C; DATA fragnent, 2 bytes 

755; 250 Data received 0K. 

§2 5707325 (ACK) Seq=73 Ack=199 Win=29696 | 
$7; DATA fragnent, 5 bytes 

95; 221 Charit's. com Service closing chant 


28 850006670, 085950000 


192, 168, 1, 104 


192, 168, 1, 105 


SMTP session 


1 


§2 57073425 [ACK] Seqs78 Ack=242 Win=29696 


Packets from 1-3 are TCP-handshake packets. The 
handshake is happening between the client and the 
server. In the fourth packet, the client receives a 
message Stating 220 as the response code. This means 
the server is available and ready to respond to the 
client's request. In the sixth packet, the client 


initializes the standard SMTP session using the teto 
command, followed by the sender's and recipient's 
email addresses, which were confirmed to be correct 
by the server, with response code 250 in packets 10 and 
13. Then there's the email body packet using the pata 
command, which was successfully received by the 
server in packet 23. In the end, the user gracefully 
closes the connection by issuing the q:t command, 
which the server confirmed in packet 2, thus 
sending Fin, ack. 


Session Initiation 
Protocol (SIP) and Voice 
Over Internet 

P rotocol( VOIP) 


SIP is a part of the VOIP family, which is a signaling 
protocol used to create, manage, and terminate VOIP 
sessions in a networking environment. Examples of SIP 
include a two-way phone call or a conference call, or 
multimedia sessions with multiple hosts. After the 
initiation of the session, the data is transferred 
through the Real time Transport Protocol (RTP) 
over the dedicated channel. Basically, the family of 
RTPs governs the transport and the flow control of all 
multimedia items (RTCP controls the flow). 


Wireshark can assemble a stream of RTP packets in 
order to play back the conversation that happened 
between two parties (use it ethically!). 


SIP runs over UDP and commonly uses port 5e60. SIP 
provides us with different call-managing features, such 
as initiating calls, disconnecting calls, adding someone 
to a conference call, and transferring calls, though SIP 
is not going to help you maintain the quality of calls. 


Let's discuss the typical VoIP infrastructure through 
the following diagram. There are three nodes: two of 


them are clients and one is the IP telephony server, 
which enables voice communication: 


Client 1 <----+----20--2-2-0= > : Sennen > Client 2 
(1) Invite---------------------- > 

(2) Tinvite accesencccesnnccsans > 
Spree 100 Trying (3) 
--(4) 180 Ringing 





es 180 Ringing (5) 

ee (6) 200 Ok 
eee -- (7) 200 Ok 
(8) ACK --222222220sseennseennssnneconeseunsesuseeesseeesseeseseuseesecaessssescesssccesceses 
a aaa da RR : 


1. Client 1 sends an Invite request to initiate the 
session using SIP. 

2. The telephony server transfers the request to 
Client 2. 

3. The telephony server acknowledges Client 1 
with the 100 Trying packet. 

4. Client 1 receives a180 Ringing packet as 
soon as Client 2 starts ringing. When Client 2 
on the other side receives the call, it sends the 
200 OK packet, which is forwarded to Client 1. 

5. Now the client sends the ACK packet to 
acknowledge the receipt of the 
200 OK packet. 


6. Now both parties are connected with a 
dedicated channel, over which the RTP/RTCP 
packets start flowing back and forth. 

7. To end the communication, there will be a BYE 
packet sent by one of the communicating hosts, 
which is acknowledged by the other end. 

8. All of the packets will be sent back and forth 
between client 1 and 2, due to information only 
known to telephony server. 

9. Once the channel created, all the packets will be 
sent and received directly by the clients without 
the server's intervention. 


For illustration purposes, I have configured a small 
VoIP telephony infrastructure using Asterisk PBX that 
can be downloaded for free. So, our VOIP server is 
located at 192.168.1.107, Client 1 at 192.168.1.104, and client 2 
at 192.168.1.107. 1am also using an X-lite calling 
application to call client 2 from client 1. The following 
is a screenshot of traffic captured in the list pane of 
Wireshark: 


5 0,001673000 192,168,1,107 192, 168,1,104 SIP §15 Status; 100 Trying | 


172 0, 085903000 192,168,107 —192,168,1,106 — SIP/SDP =» 917 Request: INVITE sip; 1016192, 168. 1, 106; 5621 
177 0,087461000 192,168,1,107 192,168,104 SIP §31 Status: 180 Ringing | 

178 0,652323000 192,168,1,106 192, 168,1,107 SIP 348 Status: 100 Trying | 

179 0, 959210000 192,168, 1,106 192.168.1107 SIP S01 Status: 180 Ringing | 

182 0, 961010000 192, 168,1,107 192, 168,1,104 SIP §31 Status; 180 Ringing | 

186 3, 827648000 192,168,1.106 — 192.168,1.107  SIP/SDP 782 Status: 200 OK | 

188 3, 829335000 192,168,1.107 192.168.1106 SIP 489 Request: ACK sip:101@192, 168, 1, 106: 56215; r 
205 3, 834786000 192,168,107 — 192,168,1,104 SIP/SDP = 820 Status; 200 OK | 

211 3,839764000 192,168,1,104 192.168.1107 SIP 482 Request: ACK sip: 101@)92, 168, 1.107 | 


1644 10, 852745000 192, 168.1,104 192, 168.1,107 SIP 641 Request: BYE sip: 101@192, 168. 1,107 | 
1645 10,853115000 192,168,1,207 192,168,104 SIP 489 Status; 200 OK | 
1652 10, 854002000 192,168,1,107 192, 168,1.106 SIP 527 Request; BYE sip: 101@)92, 168, 1, 106; 56215; r 
1690 11,042924000 192,168,1,106 192, 168,1.107 SIP 467 Status; 200 OK | 
SIP traffic 


One thing you should consider is placing the analyzer 
as Close as possible to the telephony server so that it 
will be able to capture every last packet. While 
capturing, if you cannot see any SIP packets, then you 
won't be able to capture VOIP packets as well. 


Reassembling packets 
for playback 


Yes, it is possible to assemble the VOIP packets back to 
listen to either side, or both sides, of communication. 
Let's suppose I want to listen to the message client 1 
at IP 192.168.1.104 sent to client 2 at IP 192.168.1.107. We can 
use the Telephony menu in Wireshark to reassemble 
the packets and choose the VOIP Calls option from the 
list. The following screenshot illustrates the resulting 
dialog: 


000 \ sip.poapng -VolP Cals 


Detected 2 VolP Calls, Selected 1 Call, 


Start Tin” |Stop Tim {Initial Speal | From To Protoc |Packet {State | Comments 


0,085903 1.042924 192.168.1.107 “Support” <sip:2l <sip:101@192.1¢SIP 7 COMPLET! 





Total: Calls:2 Start packets: Completed calls: 2 Rejected calls: 1 


Y Prepare Filter > Flow | 4)Player = Select All X Close 


VOIP Calls dialog 


Now choose which side of communication you want to 
listen to. Then click on the Player button and configure 
Jitter (Jitter is the variance in packet rate at which the 
packets are being sent and received. If jitter is high, 
then there is a chance that your network is dealing 
with congestion. Calls with high jitter values are not 
feasible to listen to) and Time as illustrated, and click 
on Decode: 


000 \ sinpoanng- RTP Player 
C View as time of day 





ter btn 50 O jitter buffer O Use RTP timestamp © Uninterrupted mode Decode 


Player dialog 


I did not change the default value and clicked directly 
on the Decode button, which reassembled all the VoIP 
packets for the side of communication I chose, as 
shown in the following screenshot: 


000 \ sp.pcagng «TP Player 


4 


Ofron 192,168:1,104:63398 to 192,168:1.107:17880 Duration6,88 Drop by iter uf (0, Mh) Out of eq 10. 3) Wrong Timestamp 2(0.6%) 








i) 
O From 192,168,1,107:17880 to 192,168.1,104:63398 Duration:7,02 Drop by jitter Buff0(0,0%) Out of Seq: 0(0,0%) Wrong Timestamp: 0(0.0%) 





O View as time of day 
ter bute 0 O jitter buffer OUseRTP timestamp © Uninterrupted mode ¢/ Decode ) Play | UNPause | @Stop | XClose 
RTP Player 


If you want to play the message, check the box just 
below the scrollbar and click on Play. Use this feature 





Decrypting encrypted 
traffic (SSL/TLS) 


Yes, it is also possible to decrypt your online TLS traffic 
into a plaintext SSL stream using Wireshark. Google 
Chrome and Firefox look for a log file, which stores the 
TLS session keys. Follow these steps to decrypt a 
session of encrypted traffic: 


1. Create an environment variable with the name 
ssLKEYLOGFILE that will point to a text file. Your 
browser will look for this file every time it starts 
up. To create environment variables, right-click 
on My Computer and go to Advanced Settings | 
Environment Variables | New | Specify Name. 
Enter ssikey.ocrite and Value: 

C: /Users/username/sslkeylog.txt, and 
click on OK. 
2.1 have created a blank text file, 
CG /Users/username/sslkeylog. txt 
(make your new environment variable point to 
this file). 

3. Now open your browser and visit a website 
enabled with TLS/SSL. 

For demonstration purpose, I have my own SSL 


web server located 
at 192.168.1.106 uSing a Client located at 192.168.1.105: 


y https 192 166 i 106 A 


€ Ck beps://192.168.1.106 


Test Page on My HTTPS Server 
by Charit M. 


. After you visit any secure website enabled with 
SSL, your sstkeylog.txt Will be populated with some 
random numbers, as shown in the following 
screenshot. If not, cross check your settings 
before moving on: 


CLIENT_RANDOM 17999a56ea29e69bcb242b441b1b519e 
TEL dala ctl 3766c7313Ff 
111 


. |captured the whole encrypted session traffic 
between the client and server. 
Now go to Edit | Preferences | Protocol tree | 
SSL | (Pre)-Master-Secret log filename. 
Enter /path/to/sstkeylog.txtand OK. Then right-click 
on the SSL packet (make sure you select 
Decrypt packet data. The option should be 
present in the bytes pane) and follow the SSL 


stream. Now you will see something like the 
following screenshot: 


Mice tito Connor TREE) NER 125 SS Fo cc 


File Edit View Go Capture Analyze Statistics Telephony Tools Internals Help 


COLEA BURA Ae90FS 
ae ae: 









Time Source 


19 1. 90071100 192.168.1.105 
20 1. 90165200 192. 168.1.105 
21 1. 90394300 192. 168.1.106 
22 1.90470100 192. 168.1.106 
23 1.90538900 192. 168.1.105 
24 1, 90612600 192.168.1.105 
25 1, 90829400 192,168. 1.106 
26 1. 90911000 192. 168.1.106 


28 2.11329000 192.168.1.105 
35 6. 91896000 192, 168. 1.106 


37 6. 91968000 192. 168.1.105 





Destination 


192.168.1.106 
192.168.1.106 
192.168.1.105 
192.168.1.105 
192.168.1.106 
192,168.1.106 
192.168,1.105 
192.168.1.105 


192.168.1.106 
192.168.1.105 


192.168.1.106 








Protocol 


TcP 

TLSV1.2 
TcP 

TLSv1.2 
TLSV1.2 
TLSV1.2 
TCP 
SSL 


TeP 
TLSv1.2 


TcP 


QQQh UUReB 
[+] fxpression... Clear Apply Save 


Length Info 


54 1313-443 [ACK] Seq=1 Ack=1 win=65700 Len=0 
571 Client Hello 
54 443-1313 [ACK] Seq=1 Ack=518 win=30720 Len=0 


198 Alert (Level: warning, Description: Unrecognized Name), Server Hello, Change Cipher Spec, Finis! 












105 ¢ a = - 
488 | Ml Follow SL ste a & ee 
= } Stream Content 

GET / HTTP/1.1 a ) 


664 Host: 192.168.1.106_ 
Connection: keep-alive 
85 Cache-Control: max- 


54 J) Upgrade-Insecure-Requests: 








# 
# 


@ Secure Sockets Layer 






Frame 26: 602 bytes on wire (4816 bits), 602 bytes captured (4816 bits) 
Ethernet II, Src: Apple_b9:53:ec (d8:bb:2c:b9:53:ec), Dst: LiteonTe_fa: 
@ Internet Protocol Version 4, Src: 192.168.1.106 (192,168.1.106), Dst: 1| 
@ Transmission Control Protocol, src Port: 443 (443), Dst Port: 1313 (131 


|| \Chrome/44.0.2403.155 Safari/537. 36 
ONT: 1 


‘accept-Encoding: gzip, deflate, sdch 
‘Accept-Language: en-US,en;q=0.8 


HTTP/1.1 200 OK 

Date: Mon, 17 Aug 2015 15:46:54 GMT 

Server: Apache/2.2.22 (Debian) 
Last-modified: Sat, 15 Aug 2015 09:48:32 GT 
€Tag: "153a35-5a-51d5678b364ee" 
Accept-Ranges: bytes 

Vary: Accept-Encodi 

Content-Encoding: gzip 
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85 72 8a 8b 99 43 3b fe 
8d c8 87 5b dc 47 db ac 
4e 68 85 e2 cl 7e a6 11 
7d 89 8b de 48 55 al 


nA ££ 47 sr 4 22 4s 













Content-Length: 95 
Keep-Alive: timeout=5, max=100 
Connection: Keep-Alive 

| Content-Type: text/html 











Frame (602 bytes) |Decrypted SSL data (337 bytes) | Decrypted SSL data (10 bytes) | Decrypted SSL data (7b 
(3) tug File: "C:\Users\Unknown\AppData\Local\Temp\,.. | Packets: 33 - Displayed: 16 (42.1%) « Dropped: 0 (0.0 






Entire conversation (1269 bytes) | 
find [_Sweas][ Print JO acu © EBCDIC = HexDump ©) CAays © @ Raw 
sr (ea) fia Tsim 


accept: text/html ,application/xhtml+xm1 , application/xm1; q=0. 9, image/webp,*/*;q=0.8 
Z 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) Applewebkit/537.36 (KHTML, like Gecko) 














Decrypt SSL traffic 


This is one of the easiest ways to decrypt SSL traffic 
with just a few clicks. One more way is to feed the RSA 
private key of the server into the Wireshark SSL 
preferences, which will give you the same result (I'm 
leaving it to you for your research). 


Summary 


DNS is a protocol used to resolve website names to an 
IP address. Through DNS, your machine is able 
communicate on an IP-based network. 


FTP has been used to transfer files from one machine 
to another since the internet came into existence and 
is still being used in today's modern networks. 


Web browsers present and transfer web-based content 
back and forth using HTTP. It is also commonly 
referred to as the request/response model, where a 
host requests a certain resource and the server 
responds with a status code and the resource if 
available. 


SMTP is very commonly used to send emails. The 
SMTP command and its corresponding arguments are 
passed over the wire in plaintext. 


VoIP traffic is made up of two things: RTP for data 
transfer and SIP for session creation. The signaling 
protocol creates and manages a session where RIP is 
used to carry the voice itself. 


Analyzing the Transport 
Layer Protocols TCP/UDP 


This chapter will help you understand the underlying 
technology enabling movement of network traffic 
across routing infrastructures through analysis of the 
transport layer protocols Transmission Control 
Protocol (TCP) and User Datagram Protocol (UDP). 
TCP and UDP are the basis of networking protocols 
and it is important to understand their structure and 
behavior. 


The following are the topics that we will cover in this 
chapter: 


e The TCP header and how it communicates 
e Understanding the TCP flags 


e Checking for different analysis flags in 
Wireshark 


e Understanding UDP traffic 


e Unusual patterns of TCP and UDP traffic 


We will also look at some common anomalies that 
occur in day-to-day network operations. 


The transmission control 
protocol 


TCP is a connection-oriented protocol used by several 
application-layer protocols to ensure data delivery 
without any loss of information during transition, 
based on sequence and acknowledgment numbers. 
TCP ensures fail-proof delivery of packets between 
nodes. TCP sits in between the network layer and the 
application layer and uses the IP datagram to transfer 
data packets between the sender and receiver. 


The Three-Way Handshake process takes place 
before the data transfer happens. A TCP connection is 
like a two-way communication process where not only 
the sender is actively involved, but even the receiver 
sends acknowledgments to make it a reliable form of 
connection. 


Understanding the TCP 
header and its various 
flags 

The TCP header is normally 20 bytes long, but at 
times, due to the presence of the options field, the TCP 


header size can vary up to 60 bytes. The following is an 
illustration of a simplified TCP header: 


Source port Destination port 


Sequence number 


Acknowledgement number 


Urgent pointe 





Options 


The following is a brief explanation for each of the TCP 
header fields: 


e Source port: Used by the sending side to keep 
track of existing data streams and new incoming 
connections. 


Destination port: Port number associated with 
the services offered by the destination. 


Sequence and acknowledgment numbers: 
Each side uses a sequence number to keep track 
of ordering of the packets. Acknowledgment 
numbers are used by the sender and receiver to 
communicate the sequence number that is 
either received or sent. 


Data offset: Indicates where the data packet 
begins and the length of the TCP header. The 
size can vary due to the presence of the options 
field. 


Flags: There are various types of flag bits 
present; each of them has its own significance. 
They initiate connections, carry data, and tear 
down connections: 


e SYN (synchronize): Packets that are 
used to initiate a connection. 


e ACK (acknowledgment): Packets that 
are used to confirm that the data packets 
have been received, also used to confirm 
the initiation request and tear down 
requests 


e RST (reset): Signify the connection is 
down or maybe the service is not 


accepting the requests 


¢ FIN (finish): Indicate that the connection 
is being torn down. Both the sender and 
receiver send the FIN packets to 
gracefully terminate the connection 


e PSH (push): Indicate that the incoming 
data should be passed on directly to the 
application instead of getting buffered 


e URG (urgent): Indicate that the data 
that the packet is carrying should be 
processed immediately by the TCP stack 


e CWR (congestion window reduced): 
Used by either of the parties to slow down 
transmission speed in an event of 
congestion to avoid packet loss 


e Window size: Indicates the amount of data that 
the sender can send. The size is decided during 
the handshake process to communicate and 
match the buffer size compatible for 
transmission. 


e Checksum: Used by the receiving end to 
validate the integrity of the segments. 


e Urgent pointer: Often marked as 0, used in 
conjunction with URG flag to mark immediate 


processing of a subset of message. 


¢ Options: This field length can vary due to the 
presence of various options. This field has three 
parts: the first part specifies the length of the 
option field, the second part signifies the options 
being used, and the third contains the options in 
use. One of the important options, maximum 
segment size (MSS), is also part of this field. 


e Data: The last part in the TCP header is the real 
data. 


The preceding information gives us an overview 
regarding TCP headers and the significance of various 
parts of the header. While analyzing TCP sessions, it 
becomes quite important to know about these details. 


How TCP communicates 


To understand and analyze the packets in real time, I 
have configured a server that runs at 172.16.136.129 anda 
client that runs at 172.16.136.1, as Shown in the following 
diagram: 


Client:172.16.136.1 Server:172.16.136.129 


Client-Server 


Using Wireshark, we will capture the three-way 
handshake process, which happens before the actual 
data transfer, as well as the teardown process 
(graceful termination). 


How it works 


The following screenshot depicts the various packets 
that are being generated while a client is trying to visit 
the web page hosted on http: //172. 16.136 .129: 


Use the following display filter to ease analysis: 





282 -895706969. 756684000 172,16.136.1 = 172. 16.136.129 TCP 64 52138-80 [SYN] Seq=0 Win=65535 Len=0 





283 - 1439969339, 488273000 172,16.136.129 172,16.136.1 ‘TCP 60 80-52138 (SYN, ACK] Seq=0 Ack=1 Win=2 
284 15, 671376000 172,16.136.1 = 172, 16,136,129 TCP 52 52138-80 [ACK] Seq=l Ack=] Win=13174¢ 
285 15, 672063000 172,16.136.1 = -172,.16,136,129 HTTP 375 GET / HTTP/1.1 

286 1228372207.391617000 172.16.136.129 172.16.136.1 ‘TCP 52 80-52138 [ACK] Seq=l Ack=324 Win=3072 
287 15. 672711000 172,16,136.129 = 172.16.136.1 HTTP 503 HTTP/1,1 200 OK (text/html) 

288 15, 672725000 172,16.136.1 = 172,16.136,129 TCP 52 52138-80 [ACK] Seq=324 Ack=452 Win=1: 
289 -895706969. 777480000 172,16.136.1 = 172, 16,136,129 TCP 64 52139-80 [SYN] Seq=0 Win=65535 Len=0 
290 15. 747286000 172,16, 136.129 172,16.136.1 ‘TCP 60 80-52139 [SYN, ACK] Seq=O Ack=1 Win=2 
291 714245694, 355758000 = 172,16.136.1 = -172,16.136,129 TCP 52 52139-80 [ACK] Seq=l Ack=1 Win=131744 
292 378319958, 968279000 = 172,16.136.1 = -172,16,136,129 HTTP 359 GET /favicon. ico HTTP/1.1 

293 1580695018. 460033000 = 172.16.136.129 172,16.136.1 TCP 52 80-52139 [ACK] Seq=1 Ack=308 Win=3072 
294 -459410977,038322000 172,16.136.129 172,16, 136.1 556 HTTP/1.1 404 Not Found (text/html) 
295 15, 754902000 172,16,136.1 = 172,16.136.129 TCP 52 52139-80 [ACK] Seq=308 Ack=505 Win=1: 
299 20, 679013000 172,16,136.129 172,16.136.1 TCP 52 80-52138 [FIN, ACK] Seq=452 Ack=324 ¥ 
300 609634608. 344347000 = 172.16.136.1 = 172, 16. 136.129 TCP 52 52138-80 [ACK] Seq=324 Ack=453 Win=1: 
301 20, 761722000 172,16, 136,129 172,16,136.1 TCP 52 8052139 [FIN, ACK] Seq=505 Ack=308 ¥ 
302 - 1931345972, 395708000 172.16.136.1 = 172,16.136,129 TCP 52 52139-80 [ACK] Seq=308 Ack=506 Win=1? 


A three-way handshake process is taking place in the 
packets 282, 283, and 2s to create a dedicated channel. 
The client initiated the creation by sending a syn packet 
in the 282 packet with the SEQ set to o. Since the server 
was open for communication, the server responded 
with a syn/ack packet with ack set to 1 and seq set to 4, 
followed by a confirmation sent from the client side in 
the packet number 284 with seq=-1 and ack=1. 


After the successful completion of channel creation, 
the client sends a cet request to access the contents of 
the web-root directory. The server acknowledges this 
in the packet number 2s7 and sends the requested 
content with the 200 o status message, which is 
acknowledged by the client in the next packet. 


After all the data transfer takes place, when the client 
has nothing left to request, or when the server has 
nothing left to send, the client sends Fi1n/ax packets to 
properly terminate the connection. The server 
acknowledges this and sends its own rin/ack packets, 
which are acknowledged by the client in the packet 
number 302. This way of termination is often referred to 
as the teardown process. Refer to the following 
screenshot, which illustrates this process: 


299 20, 679013000 172. 16,136,129 172,16. 136.1 T¢P 52 80+52138 [FIN, ACK] Seq=452 Ack=324 
300 609634608, 344347000 = 172. 16, 136.1 172, 16,136,129 TCP 52 52138-80 [ACK] Seq=324 Ack=453 Win=] 
301 20, 761722000 172.16.136.129 172.16, 136.1 TCP 52 80-+52139 [FIN, ACK] Seq=505 Ack=308 
302 - 1931345972, 395708000 172.16, 136.1 172, 16,136,129 TCP 52 52139-80 [ACK] Seq=308 Ack=506 Win=1 














172.16.136.1 
172.16.136.129 


Time 


-895706969.7566 
-1439969339.488 
15.671376000 
15.672063000 
1228372207.3916 
15.672711000 
15.672725000 
-895706969.7774 
15.747286000_: 
714245694.35575: 
378319958 .96827 
1580695018.4600 
-459410977.0383 
15.754902000 
20.679013000 
609634608 .34434 
20.761722000 
~1931345972.395 | 








Comment 


Seq =0 

Seq =0 Ack=1 

Seq = 1Ack=1 

Seq =1Ack=1 

Seq = 1 Ack = 324 
Seq = 1 Ack = 324 
Seq = 324 Ack = 452 
Seq =0 


:Seq = 0 Ack =1 
‘Seq = 1 Ack =1 


Seq =1Ack=1 

Seq = 1 Ack = 308 
Seq = 1 Ack = 308 
Seq = 308 Ack = 505 
Seq = 452 Ack = 324 
Seq = 324 Ack = 453 
Seq = 505 Ack = 308 
Seq = 308 Ack = 506 


How sequence numbers 
are generated and 
managed 


You must be wondering who assigns sequence number 
to packets and how. The device that initiates 
connection uses Initial Sequence Numbers (ISN) 
that are generated by the host's operating system. It 
can be any random number that has no significance 
with respect to the data. The sequence number we see 
in the packet one is zero is a relative referencing 
technique used by Wireshark. 


Starting from packet 1, where seco (the relative 
sequence number in real is 704809601), which is received 
by the server and in return replies with its own seo-0 
and ack-1 for the client's seq-o. At the end of this three- 
way handshake, the client replies with seo-1 and ack=1 
without any further increments as no data is being 
transferred during the process. 


Then, by the fourth packet, the client sends a cet 
request with seq-1 and acx-1 where the data payload 
length equals 323 (refer to the following screenshot), 
which the server receives and acknowledges with sea-1 
and acx-324. Did you see what just happened? The server 
replied by adding a total data payload length into ax to 
denote that the data was successfully received: 


Source Port: 52138 (52138) 

Destination Port: 80 (80) 

[Stream index: 7] 

[TCP Segment Len: 323] 

Sequence number; 1 (relative sequence number) 

(Next sequence number: 324 (relative sequence number) ] 





RST (reset) packets 


Often, there will be situations such as the server 
daemon is not available/running, the server is not able 
to process your request due to overload, you are 
restricted to interact with the server, or the port you 
are trying to connect to is not ready/open for 
connections. The rst packet basically denotes the 
abrupt rejection of a connection request. 


In our scenario, the server daemon is not running and 
the client is trying to communicate; as a result, it 
receives rst packets in return for every syn request 
sent. The client tries visiting the web page just once, 
but Wireshark captures more than one syn and rst 
packet because every browser performs a different 
number of attempts over a non-responding or a closed 
socket at a preconfigured interval. Hence, in our case, 
I am using the Apple Safari browser, which made three 
attempts to connect in a span of 3-4 minutes. Refer to 
the following screenshot, which illustrates the packets 
captured in the process: 


77 +1440231980, 381381000 172,16,136,1 — 172,16,136.129 TCP 64 55792-80 [SYN] Seq=0 Win=65535 | 
18 13, /44 172,16,136,129 = 172.1 | ‘ ; 
79 13, 745349000 72,16,136,1 172,16, 136,129 TCP 





64 5579380 [SYN] Seq=0 Win=65535 | 


97 -1440231980,420122000 172.16,136,1 = 172,16,136,129 TCP 64 55794-80 {SYN} Seq=O Win=65535 


136, 1 





000 i] 172.16.196,129 GOELRIQIAA 





Safari Cant Connect to the Server 


Safari can't open the page “172. 16,196, 29" because Safari can't connect to the 
server "172,16,196,120", 


Unusual TCP traffic 


Lost connection or unsuccessful connection attempt 
scenarios are the most common forms of unusual TCP 
traffic. You might also observe several other scenarios, 
such as high latencies due to long-distance 
communications. To make the analysis convenient and 
easy to troubleshoot, use the time column by sorting it 
to figure out large time gaps between the packets at 
the top of the list pane. 


Another example can be where a malicious device is 
running a port scan on your network and your firewall 
responds with rst packets to avoid such reconnaissance 
attacks, or it might also be possible that the port 
closed. Refer to the following screenshot, where I've 
tried scanning a node over network using nmap, and it 
seems quite visible (due to a lot of packets generated 
from one source destined for random port numbers), 
and hence is easy to track: 


17 42, 896242000 172,16,136.129  172,16.136.1 TCP 44 52604993 [SYN] Seq=1 
18 - 1440527712, 212734000 172.16, 136.1 172.16.136.129 TCP 40 993452604 [RST, ACK] 


20 42, 896542000 172.16,136,129 TCP 40 21452604 [RST, ACK] $ 
21 - 1440526406, 274558000 172.16.136,129 172,16, 136.1 TCP 44 52604113 [SYN] Seq=l 
22 - 1440529409, 791742000 2 cP 40 113452604 [RST, ACK] 

23 42,897040000 172,16,136.129 = 172,16.136.1 TCP 44 52604554 [SYN] Seq=l 
24 - 1440529413, 396222000 172.16.136,1 172,16,136.129 TCP 40 55452604 [RST, ACK] 

25 42,897314000 172,16.136.129 = 172.16.136.1 TCP 44 52604-143 [SYN] Seq=l 
26 42,897326000 : 172,16,136.129 TCP 40 143452604 [RST, ACK] 

27 - 1440527002, 586622000 172.16.136.129 172,16.136.1 ‘TCP 44 52604-111 [SYN] Seq=l 
28 - 1440529304, 344318000 172.16.136.1 172,16,136,129 TCP 40 11152604 [RST, ACK] 

29 - 1440529409, 461758000 172.16.136.129 172,16.136.1 ‘TCP 44 52604-256 [SYN] Seq=1 
30 42, 897884000 172, 16, 136.1 172.16, 136,129 TCP 40 25652604 [RST, ACK] 

31 - 1440529409, 461758000 172,16.136.129 172,16, 136.1 TCP 44 52604-8888 [SYN] Seq= 
32 42,898151000 172, 16, 136.1 172, 16, 136, 129 

33 - 1440529409, 461758000 172.16.136.129 172, 16. 136.1 TCP 44 52604-3389 [SYN] Seq= 
34 42, 898425000 172, 16, 136, 129 
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Frame 19; 44 bytes on wire (352 bits), 44 bytes captured (352 bits) on interface 0 

Raw packet data 

Internet Protocol Version 4, Src: 172.16, 136.129 (172.16. 136.129), Dst: 172.16. 136.1 (172.16. 136, 1) 

Transmission Control Protocol, Src Port: 52604 (52604), Dst Port: 21 (21), Seq: 1024978624, Len: 0 
Source Port: 52604 (52604) 


Observe Frame 19, Where the port scan initiated sents a syn 
packet in order to check whether the port is open or 
closed. As a result, port 21 (rte) was closed; hence the 
server sent an rst packet. There can be various 
scenarios other than the one discussed previously. If 
you hold a strong basic working knowledge of TCP and 
IP then it would be quite easy for you to point out 
unusual forms of traffic. 


The User Datagram 
Protocol 


As defined in RFC 768, a UDP is a connectionless 
protocol, which is great for transmitting real-time data 
between hosts and is often termed as an unreliable 
form of communication. The reason is, UDP doesn't 
care about the delivery of packets, and any lost 
packets are not recovered because the sender is never 
informed about the dropped or discarded packets. 
However, many protocols such as DNS, TFTP, SIP and 
so on. rely only on this. 


The protocols that use UDP as a transport mechanism 
should rely upon other techniques to ensure data 
delivery and error-checking. A point to note is that 
UDP provides faster transmission of packets as it does 
not perform three-way handshake or graceful 
termination as observed in the TCP. UDP is referred to 
as a transaction-oriented protocol and not a message- 
oriented protocike a Tol ICP. 


The UDP header 


The size of a usual UDP header is 8 bytes; the data 
that is added with the header can be theoretically 
65,535 (practically 65,507) bytes long. A UDP header 
is quite small when compared to a TCP header; it has 
just four common fields: Source Port, Destination Port, 
Packet Length, and Checksum. Refer to the UDP 
header shown here: 








Source Port Destination Port 
Packet Length Checksum 8 bytes 





Application Data 





e Source port: Port number used by the sending 
side to receive any replies if needed. Most of the 
time, in a TCP and UDP the port number chosen 
to be the part of the socket is ephemeral. 


e Destination port: Port number used by the 
receiving side, where all data is transmitted to. 


e Packet length: Specifies the length of the 
packet, starting from the header to the end of 
the data; the minimum length you will observe 


will be 8 bytes, that is the length of the UDP 
header. 


Checksum: Data integrity ensures that what is 
sent from the sender side is the same as what 
receiver got. Sometimes, while working with a 
UDP you will see that the checksum value is o in 
the packet received. This means that the 
checksum is not required to be validated. 


How it works 


Let's analyze protocols such as DHCP, DNS, and TFTP 
which use UDP as a delivery protocol. 


I have configured a default gateway at 192.168.1.1 and a 
client at 192.168.1.10. Wireshark running between them 
will capture the UDP transactions. The following is a 
reference architecture diagram: 


Default Gateway IP: Client IP 192.168.1.106 
192.168.1.1 


The DHCP 


The protocol that manages IP addresses assigned to 
nodes and makes them network communication 
compatible is the Dynamic Host Configuration 
Protocol (DHCP). It is an automated way of assigning 
and managing IP addresses to requesting devices. 


To generate DHCP packets from a client machine 
assigned with an IP address, I will try to release the 
current IP. Refer to the following screenshot: 


2 2.340484000 192.168.1.106  192.168.1.1 DHCP 342 DHCP Release 





saaeaas 


b Frame 2; 342 bytes on wire (2736 bits), 342 bytes captured (2736 bits) on interface 0 
b Ethernet II, Src: Apple_b9:53:ec (d8:bb:2c:b9:53:ec), Dst: Zte_07:73:6c (dO: 5b:a8:07:73:6c) 
b 


Vv User Datagram Protocol, Src Port: 68 (68), Dst Port: 67 (67) 2] 
Source Port: 68 (68) 


Destination Port: 67 (67) 3 | 
Length: 308 | 4 

b Checksum: Ox™*O5" [validation disabled] 
[Stream index: 0] 


In the list pane, we can see a DHCP release packet 
that was sent explicitly by the client (I used the anctient -v 
-r command on the Linux Terminal to release the IP 
address). 


The DHCP server port number is 67 and the DHCP 
client port number is 6s by 

default. There is a fourth field that I have highlighted, 
the packet length field, which specifies the length of 
the packet, starting from the first byte until the end of 





The TF TP 


The Trivial File Transfer Protocol (TFTP) isa 
lightweight version of the FTP that is used to transfer 
files between devices. Unlike the FTP protocol, TFTP 
does not ask users for any credentials. TFTP uses UDP 
as a transport mechanism. 


Most commonly, TFTP is used in LAN environments 
and, when dealing with manageable devices such as 
switches and routers, network administrators use 
TFTP servers to take back up of configuration files and 
to update the firmware. 


TFTP server is running at IP 192.168.1.106 and a TFTP 
client at IP 192.168.1.104. There is a text file abc.txt stored on 
the TFTP server, which the TFTP client will download. 
Refer to the following diagram: 





TFTP Client: 192.168.1.104 


TFTP Server: 192.168.1.106 


The traffic generated between two hosts is successfully 
captured and the packets corresponding to it are 
shown in the following screenshot 







Filter: ftp | Expression. Clear Apply Save 


Destination | Protocol] Length| Info 
192, 168, 1, 106 89 Read Request, File: abc. txt, 









58 15, 950236000 192, 168.1, 104 





59 15, 986825000 192,168.1,106 192,168.1.104 —‘TFIP 75 Option Acknowledgement, tsize 
60 15, 989415000 192,168.1,104 192,168.1,106 — ‘TFIP 46 Acknowledgement, Block: 0 
61 15,989907000 192, 168.1.106  192.168.1,104 —TFTP 49 Data Packet, Block: 1 (last) 
62 15, 992283000 192,168.1,104 192,168.1,106 —‘TFIP 46 Acknowledgement, Block: 1 


saaaaae 





b 
b Ethernet II, Src: LiteonTe fa:5e:b4 (20:68:9d:fa:5e:b4), Dst: Apple b9:53:ec (d8:bb: 2c:b9:53:ec) 
b Internet Protocol Version 4, Src: 192,168, 1,104 (192, 168,1.104), Dst: 192,168.1.106 (192, 168, 1, 106) 
V User Datagram Protocol, Src Port: 51118 (51118), Dst Port: 69 (69) 
“Source Port: 51118 (51118) 
Destination Port: 69 (69) 
[engi 55 SSCS 
b Checksum: Oxc621 [validation disabled] 
[Stream index: 5] 
Vv Trivial File Transfer Protocol 


[Source File: sc] 
Opcode: Read Request ( 
Source File: abc, txt 
Type: octet 
b Option: blksize\o00 = 512\000 


b Option: timeout\o00 = 10\000 
b Option: tsize\000 = 0\000 


Now, let's see what each pointer signifies: 


1. Depicts transfer of the packets is initiated as 
soon as the client requests the abc.txt file. The 
request frame can be seen in the list pane. 

2. As discussed, a TFTP uses a UDP for a transport 
mechanism. The related details for the request 
are shown in the details pane, which states that 
the request was initiated from an ephemeral 
port number from the client destined to port 69 


on the server (69 is a default port to the TFTP 
protocol). 

3. The request was specific to the abc.txt file that is 
also present in the details pane in the TFTP 
protocol section. 


Some applications use a UDP as a transport protocol 
and have their own built-in feature to ensure delivery. 
You must be wondering about the acknowledgment 
packets that are shared between the two hosts. As we 
discussed, a UDP is an unreliable form of 
communication, so why are we seeing acs in a UDP? 
The reason is that the TFTP server we are requesting 
has a built-in reliability feature. 


Unusual UDP traffic 


The following are a few traffic patterns that may be 
found suspicious in some environments. 


Scenario 1: In a scenario where the UDP service is 
not running/available, what will the traffic look like 
then? Refer to the following screenshot: 


Filter: |tftp 7 | Expression. Clear Apply Save 


No. — | Time Source Destination | Protocol} Length} Info 


9 3, 109903000 192,168.1.106  192,168.1.104 —TFIP 61 Error Code, Code; File not found, 


The client requested an invalid resource that the 
server couldn't locate and hence returned with an 
error code and the summary messadE Fite not found (Seen 
in the list pane). 


Scenario 2: Sometimes, it is possible that the server 
daemon may not be running and the client may 
request a certain resource. In such cases, the client 
would receive the icmp destination unreachable Error with the 
error code 3. Refer to the following 

screenshot: 


Filter: |tftp + Expres. Clear Apply Save 


No, | Time Source Destination | Protocol] Length/ Info 
5 6, 170384000 192,168.1,104 192, 168.1.106  TFTP 89 Read Request, File: abc. txt, Transfer type 


) Frame 6: 117 bytes on wire (936 bits), 117 bytes captured (936 bits) on interface 0 
b Ethernet IZ, Src: Apple b9:53:ec (d8:bb:2c:b9:53:ec), Dst: LiteonTe fa:5e:b4 (20:68: 9d: fa: Se: b4) 
) Internet Protocol Version 4, Src: 192,168,1,106 (192.168,1,106), Dst: 192, 168.1, 104 (192, 168, 1, 104) 
Y Internet Control Message Protocol 
Type: 3 (Destination unreachable] 2 
Code: 3 (Port unreachable) 
Checksum: 0x8168 [correct] 
) Internet Protocol Version 4, Src: 192.168.1104 (192,168.1.104), Dsti192, 168, 1,106 (192, 168. 1. 106) 
V User Datagram Protocol, Src Port: 51183 (51183), Dst Port: 69 (69) 
Source Port: 51183 (51183) 
Destination Port: 69 (69) 
Length: 55 
b checksum: OxcSe0 [validation disabled] 
[Stream index: 1] 
V Trivial File Transfer Protocol 
Opcode: Read Request (1) 
Source File: abe, txt 
Type: octet 
b Option: blksize\000 = 512\000 
) Option: timeout\000 = 10\000 
b Option: tsize\o00 = 0\000 





Let's discuss what each pointer signifies in more 
detail: 


1. The server returned with an tcwp destination unreachable 
message when the TFTP server daemon was not 
functional 

2. The client received an error code of type 3 

3. The request was sent to port 69, which was 
currently nonfunctional 


4. The requested resource shown under the TFTP 
protocol section 


Scenario 3: Unusual DNS requests are also often 
seen when a client initiates a request to look for name 
servers associated with an address. It would look like 
the one shown in the following screenshot: 







No. | Time Source Destination — | Protocol] Length| Info 


1 0,000000000 192, 168.1,106 192, 168,1.1 DNS ro" 80 Standard query Ox8a40_PTR 0.0.0.8.in-addr. arpa 
2 0,004784000 192,168. 1,1 192,168,1,106 ONS 80 Standard query response Ox8a40 No such name 


Orerere 


b Frame 2; 80 bytes on wire (640 bits), 80 bytes captured (640 bits) on interface 0 
) Ethernet II, Src: Zte_07:73:6c (d0:5b:a8:07:73:6c), Dst: Apple b9:53:ec (d8:bb: 2c:b9:53:ec) 
> Internet Protocol Version 4, Src: 192, 168.1.1 (192,168.1.1), Dst: 192,168.1.106 (192, 168, 1, 106) 


i) 
Y Domain Name System (response) | | 


[Request In: 1] 
[Time; 0,004784000 seconds] 
Transaction ID; 0x8a40 
b Flags: 0x8183 Standard query response, No such v3] 
Answer RRs: 0 
Authority RRs: 0 
Additional RRs: 0 
) Queries 





Now we will see what each pointer signifies: 


1. As seen in the list pane, the client at 192.168.1.106 
initiated a request to look for the address 8.0.0.9 
and received a reSponse iM Frame 2 No such Name 

2. The request was sent to the default gateway 
that holds the DNS cache 

3. The gateway responded with a no such name EYYOr 


There can be multiple scenarios where you will see 
unusual traffic related to UDP. Based on your usual 
network activity, it is advisable to create a traffic 
pattern to identify anomalies in DNS, DHCP, TFTP and 
so on. UDP protocols. 


Learn about malicious DNS traffic to protect your digital 
infrastructure. 


Summary 


TCP is a reliable form of communication that facilitates 
three-way handshakes that and a teardown process 
ensures the connection is reliable and interactive. 


A TCP header is 20 bytes long and consists of various 
fields such as source and destination port, seo and ac 
numbers, offset, window size, flag bits, checksum, 
and options. 


The seg and ak numbers are used by TCP-based 
communications to keep track of data sent across. 


A UDP is a connectionless protocol that is a nonreliable 
means of communication over IP where the lost and 
discarded packets are never recovered. A UDP does 
provide 

faster transmission and easier creation of sessions. 


A UDP header is 8 bytes long and has very few fields, 
such as source and destination port, packet length, 
and checksum. Common protocols such as DHCP, TFTP, 
DNS, and RTP mostly use a UDP as a transport 
mechanism. 


Network Security Packet 
Analysis 


Wireshark is an efficient utility packed with an 
advanced set of features that assist security 
professionals in performing passive analysis of network 
traffic to identify and point out malicious packets and 
anomalies. 


This chapter will guide you through how to use 
Wireshark to analyze security issues, such as analyzing 
malware traffic and footprinting attempts. We will 
cover the following topics: 


Analyzing port scanning, footprinting, and 
attack/exploitation network traffic 


Dissecting malicious ARP traffic 


Analyzing brute force attacks 


e Inspecting malicious traffic 


Creating display and capture filter signatures 
for malicious traffic 


Using real-life scenarios simulated in a virtual network 
infrastructure, we will capture and understand 
malicious traffic patterns and replicate attacks such as 
information gathering and exploitation attempts. We 


will start from information gathering activity followed 
by an exploitation through a malicious .exe file. Then we 
will move on to understanding ARP poisoning traffic 
commonly used for performing man-in-the-middle 
(MiTM) attacks. 


Information gathering 


The probability and success factor of every attack 
depends on information gained through passive and 
active scanning of the network. Footprinting and 
reconnaissance are synonyms for the term information 
gathering. 


The following diagram depicts the virtual/physical 
infrastructure we will be using for our analysis and for 
replicating the attacks: 


Mobile y Access Point 
Devices 

) 
(eat 


4, 4 
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The access point is located at 192.168.1.1 and it allocates 
the IP address to connected devices using DHCP; the 
attacking box (Kali) is configured with a manual IP 
address 192.168.1.106. 








PING sweep 


Let's begin with our first scenario, where an attacker 
is trying to perform a ping sweep attack over the 
subnet his machine is a part of (assumption: The 
attacker is an internal employee). Refer to the 
following screenshot, which displays displays the 
traffic captured as a result of running a bash script 
(ping sweep scan); the script pings each IP starting 
from 192.168.1.100 CO 192.168.1.110: 


No, | Time 


1 0,000000000 
2 0,.004128000 
3 0,008476000 
4 0,012705000 
5 0,.023785000 
6 0,027774000 
7 0,031652000 
8 0,035462000 
9 0,040423000 
10 0,047374000 
11 0, 122601000 
12 0, 124979000 
13 0, 125118000 


15 0, 131304000 
16 0,438404000 
17 0,528177000 


Source 

Apple b9: 53; ec 
Apple_b9; 53; ec 
Apple_b9: 53;ec 
Apple_b9: 53: ec 


192, 
192, 


168.1, 106 
168, 1, 104 


Apple _b9: 53: ec 


192, 
192, 
192 





168. 1, 106 
168.1, 106 
168.1, 106 








LiteonTe_fa:5e: b4Broadcast 
Apple_b9: 53: ec 
192, 168, 1, 100 


192, 168, 1,101 
Apple b9: 53: ec 
Ite 07:73:6¢ 


Destination 
Broadcast ARP 
Broadcast ARP 
Broadcast ARP 
Broadcast ARP 
192, 168.1, 105 ICWP 
192, 168, 1, 106 ICP 
Broadcast ARP 
192, 168, 1, 102 ICH 
192, 168.1, 101 ICWP 
192, 168, 1, 100 ICMP 
ARP 
LiteonTe fa:5e:b4 ARP 
192, 168, 1, 106 ICP 
192, 168, 1, 106 ICWP 
Zte_07;73: 6c ARP 
Apple b9:53:ec ARP 
Ping sweep 


Protocol| Length Info 


42 Who has 192, 168.1,110? Tel 


42 Who has 192, 168.1,109? Tell 
42 Who has 192, 168.1,108? Tell 


192, 168, 1, 106 
192, 168, 1, 106 
192, 168.1, 106 


42 Who has 192, 168.1107? Tell 192, 168, 1. 106 


98 Echo (ping) request id=Ox1 
98 Echo (ping) reply  1d=0x1 
42 who has 192,168.1,103? Tel 





1a8, seq=1/256, ttl=64 
1a3, seq=1/256, ttl=64 


192, 168, 1, 106 


98 Echo (ping) request id=0x1199, seq=1/256, ttl=64 
98 Echo (ping) request id=Ox1194, seq=1/256, ttl=64 


98 Echo (ping) request id=0x1 


18f, seq=l/256, ttl=64 
42 Who has 192, 168.1, 106? Tell 


192, 168.1, 105 


42 192,168,1,106 is at d8;bb: 2c;b9: 53; ec 


98 Echo (ping) reply  id=0x1 


98 Echo (ping) reply  id=0x1 





l8f, seq=1/256, ttl=64 


194, seq=1/256, ttl=64 


42 Who has 192, 168.1,1? Tell 192, 168, 1, 106 
42 192,168.1.1 1s at dO: 5b:a8: 07; 73: 6¢ 


Starting from packets 1-4, ARP requests are observed 
because of the ICMP ping command issued on Kali and, 
as it is fresh network, configuration devices would 
need to build their ARP cache table for internal LAN 


communication. In packet 5, the ping request is sent to 
192.168.1.105, and the reply for it is received in packet 14, 
which means the device is available. A similar pattern 
of traffic is captured and observed for the other IPs in 
the DHCP range. Due to frequent ARP and ICMP 
packets observed for a series of IPs one after another, 
we can conclude that it is a port scanning activity on 
the LAN network. 


Half-open scan (SYN) 


Now let's scan a specific device in the range of IP 
addresses and target the machine running at IP 
192.168.1.105. [he primary way to gather information 
pertaining to a specific device would be a port scan in 
order to check for any open services that target device 
offers. By services, I mean HTTP daemons, mail server 
daemons, FTP server, SMB, and so on. 


You might be wondering what a half-open scan is. Look 
at the process of a TCP three-way handshake we 
discussed in the previous chapter, where the client 
initiates the connection by sending a sw packet and if 
the server is available client receives the syy, ack packet, 
and in return, the client sends an ax packet to the 
server for completing the handshake process. 


Now, what would happen if the ax packet sent in the 
last step of the TCP handshake is never sent to the 
server? The server will wait for a period of time before 
terminating the handshake process, and the 
connection to the specific TCP service would never be 
completed. That's why this type of scan is called a half- 
open scan. 


I have executed a half-open scan from the Kali box at 
IP 192.168.1.10 to target the Win7 box at IP 192.168.1.105 
using Nmap with -sS switch. Nmap is an open source 
port scanning tool available for most platforms and can 
be downloaded for free from http: //nmap.org. The traffic 


generated because of the svn scan we executed is 
captured and shown in the following screenshot (use 
display filters for viewing packets pertaining toa 
specific host as follows): 








+ |bpesion, Clear Apply Save 


No, | Time Source Destination Protocol| Length| Info 
13 0312790000 192,168,1.106  192,168.1.105 TCP $8 34006-53 [SYN] Seq=1408496563 Win=1024 Len=0 NSS=1460 


Filter: lip 





19 0, 313759000 192,168,1,106 192,168. 1, 105 TP 58 34806-80 [SYN] Seq=1408496563 Win=1024 Len=0 MSS=1460 





Halfopen scan 


The key points/patterns to note in the above listed 
packets are as follows: 


e There are numerous sw packets generated from 
IP 192.168.1.106 destined for IP 192.168.1.105 Over 
random ports within a very little amount of time. 
It is highly unlikely that an internal machine will 
initiate multiple connection instances within 
such short time frame (look at the time column). 


e In the packets starting from 13 to 22, a syn 
request is being sent so frequently over random 
and well-known port numbers within 
milliseconds. 


e Also, the host at IP 192.168.1.106 never sent back a 
ack packet in response to syn, ack received. 


OS fingerprinting 


Being aware of the operating system running on the 
target takes the information gathering process to the 
next level. If the make and version of operating system 
running is known to the attacker, it gives an extra edge 
in terms of exploitation through targeting specific 
vulnerabilities. 


How do you think identifying the remote machine's OS 
works? I will tell you the secret. Every OS has a 
different way of implementing the TCP stack. So, a 
packet when received from the remote machine will 
have certain fields in it, such as TTL, fragment offset, 
and window size. By comparing the values in the 
packet with the database, tools are able to predict the 
OS with greater accuracy. For example, if you try to 
ping a Windows machine, the TTL value returned 
would be 128, and if you ping a Linux machine, the 
TTL value would be 64 most of the time. Simple, isn't 
ite 


Using the nmap command nmap -0 192.168.1.109, 192.168.1.104, let 
us fingerprint a machine's OS for IP 192.168.1.109 and 
192.168.1.104 and capture the generated traffic. 


We won't just rely on nmap's output to confirm the OS; 
we will also try to dissect packets from Wireshark for 
more clarity. Refer to the following screenshots to 
compare the outputs: 


109) 11, 210877000 192.168.1104 192.168.1106 1? 78 3609-36142 (SYM, ACK] Seq=2282582) 


Identification; O148¢6 (18630) 
b Flags: 0x02 (Don't Fragen) 
Fragnent offset: 0 
Tite to Live: 64 
Protocol: 1¢P (6) 
D Header checksum: Oxtdet [correct] 
Source: 192,168,1,104 (192, 168.1, 108) 
Destination: 192, 168.1, 106 (192, 168,1.106) 
(Source GuotP; Unknown) 
(Destination Geot?: Unknown) 


Source Port; 3689 (3689) 
Destination Port; 36142 (36142) 
(Stream index; 1007) 

(TCP Segment Len: 0] 

Sequence number; 2282552026 
Ackncnlledgment nveber; 2031158175 
Header Length: 44 bytes 


Window size value; 65535 
(Calculated window size: 65535] 
Checksum; 018¢87 [validation disabled) 
Urgent pointer; 0 
Y (ptions: (24 bytes), Maximun seqnent size, No-Operation (MOP), window scale, No-Cperation (NOP), No-Operation (NOP), 
at Wobtes 


109) 11.210577000 192.168.1104 192.168.1106 1? 18 3609-36142 SYN, ACK) $eq=2282582| 


Tdentification; Oxtde6 (18630) 

D Flags: Ov02 (Don't Fragnent) 
maar 
Tite to Live: 64 
Protocol: TCP (6) 

D Header checksum: Oxtdet (correct) 
Source: 192,168,1,104 (192, 168.1. 104) 
Destination: 192,168.1, 106 (192. 168.1.106) 


(Source GeolP: Unknown) 
{Destination Geot?: Unknown) 


Source Port: 3689 (3689) 
Destination Port; 36142 (36142) 
(Stream index; 1007) 

(TCP Segment Len: 0] 

Sequence number: 2282552026 
Acknowledgment nveber; 2031158175 
Header Length: 44 bytes 


Window size value; 65535 
(Calculated window size: 65535] 

D checksum; 0x8¢87 [validation disabled) 
Urgent pointer: 0 

Options: (24 bytes), Maximum seqnent size, Mo-Operation (NOP), Window scale, No-Cperation (NOP), No-Operation (NOP), 


198 18, 196700000 192, 168,1.109 192,168, 1, 106 it 58 135-6284) (SYN, ACK] 
foray Conguns 44 
Identification; Ox045¢ (1116) 

D Flags: 0x00 
Fragnent offset; 0 
Tine to live: 128 
Protocol: TCP (6) 

D Header checksum: Oxb24B [correct] 
Source: 192,168,1.109 (192. 168.1. 109) 
Destination; 192,168.1,106 (192. 168, 1, 106) 
(Source GeotP: Unknown) 
(Destination GeoTP; Unknown) 


Source Port; 135 (135) 
Destination Port; 62841 (62841) 
[Stream index: 25) 

(TCP Segment Len: 0) 

Sequence number: 4083218279 
Acknowledgment number; 4123706089 
Header Length: 24 bytes 


Window sive value: 64240 
(Calculated window size; 64240) 

D Checksum; Ox747F [validation disabled) 
Urgent pointer; 0 

Y Options: (4 bytes), Maximum segment size 


) Maximum segnent_size:_1460 bytes 


D [SEQ/ACK analysis) 


198 18, 196700000 192, 168,1.109 192, 168.1, 106 it 58 13562841 (SYN, ACK] 
fora Lengens 44 
Identification; Ox045¢ (1116) 


D Flags: 0x00 


Fragnent offset: 0 
ine to live: 
Protocol: TCP (6) 
D Header checksum: Oxb24B [correct] 
Source: 192,168,1.109 (192.168. 1. 109) 
Destination: 192.168.1.106 (192. 168.1. 106) 
(Source GeotP: Unknown) 
(Destination GeolP; Unknown) 


Source Port; 135 (135) 
Destination Port; 62641 (62841) 
(Stream index: 25) 

(TCP Seqnent Len; 0) 

Sequence number: 4083218279 
Acknowledgment number: 4123706089 
Header Length: 24 bytes 


Window size value: 64240 
(Calculated window size; 64240) 

D Checksum: Ox7E7F [validation disabled) 
Urgent pointer; 0 

Y Options: (4 bytes), Maxim seqnent size 


) Maximum segnent_size:_1460 bytes 








|__|) Aaron stone sine 1460 bytes | | TstyAace analysis) 


Check the highlighted TTL field value, which is equal 
to 64 for a Linux box and 128 for a Windows box. Also 
look at the maximum segment size value at the bottom 


where the value for a Linux box is 1460 and 1440 for a 
Windows box. Tools such as nmap store all these 
baseline values, which are then compared with scan 
results internally to identify the remote OS. A few key 
points to note to identify such malicious traffic are as 
follows: 


e Traffic generated from the scans targeting to 
identify remote OS would be similar to the syn 
scan (half-open) traffic, where the incomplete 
TCP handshakes and ice request/replies were 
observed. 


e Also, if a lot of rst or rst, ack packets are sent from 
a critical server to a specific host in a network, 
then it is something worth investigating further. 


ARP poisoning 


Whenever any device intends to communicate with 
another device, the requesting device sends a 
broadcast to the whole subnet. Then, the device to 
which the IP address belongs replies with its MAC 
address using a unicast packet. Through this 
approach, devices in local area network communicate 
with each other. A MAC address (physical address) 
table stores MAC address with its corresponding port 
number/IP address. 


Use the arp -e command to populate the ARP table 
entries on your machine. The same command on a 
majority of platforms. 


The following are some details pertaining to the local 
network we will be using for understating: 


Device IP address MAC address 


Router 
(default f92-tGontel DO:5B:A8:07:73:6C 
gateway) 


Apple 192.168.1.103 D8:BB:2C:B9:53:EC 
(victim) 
Windows 192.168.1.109 00:0C:29:B3:CB:B6 
server 
(victim) 


Kali Linux 


192.168.1.106 00:0C:29:5D:A7:F7 
(attacker) 


For instance, if the Apple machine wishes to 
communicate with the Windows machine located at 
192.168.1.109, Apple will send a broadcast asking for the 
Windows MAC address stating who has 192.168.1.109? Tell 
192.168.1.103. Lhen, aS soon as the Windows machine gets 
to know about the request, the ARP reply unicast 
packet stating 192.168.1.109 is at 00: oc: 29: 63: cB: Bs Will be sent. 


ARP poisoning is an attack form to 


poison/infect/corrupt the local ARP cache of the victim. 
Refer to the following diagram: 


Apple & ealewsy Windows 


ial —s—- alle 


Traffic being intercepted by Attacker 








Kali - ies 


IP forwarding is preconfigured using the command echo 
‘ l' /proc/sys/net/ipv4/ip_forward ON a Kali box to send traffic back and 
forth between the Apple and Windows box. 


Perform the following steps in order to replicate a 
MiTM attack in an lab environment: 


1. The following screenshot shows the ARP table 
entry for both the client and server, before the 
attacker poisons the ARP cache for the victim 
machines: 


c\ Command Prompt ’ J 


:\Documents and Settings\Administrator>arp —a 






Interface: 192.168.1.109 --- 6x10083 

Internet Address Physical Address Type 

192.168 .1.183 d8-bb-2c-h?-53-ec dynamic 

192.168 .1.106 @0-@c-29-Sd-a?-£? dynamic 

:\Documents and Settings\Administrator> x. 
A —— = WA 
Windows server cache 
Anonymous:~ NotFound$ arp -a 
? (172.16.136.1) at @:50:56:c0:0:1 on vmnet1 ifscope permanent [ethernet] 
? (172.16.158.1) at @:50:56:c0:0:8 on vmnet8 ifscope permanent [ethernet] 
? (192,168.1.1) at d:5b:a8:7:73:6c on enl ifscope [ethernet] 
? (192,168.1.100) at f@:c1:f1:63:41:95 on enl ifscope [ethernet] 
? (192.168.1.106) at @:¢:29:5d:a7:f7 on enl ifscope [ethernet] 
? (192,168.1.109) at @:¢:29:b3:cb:b6 on enl ifscope [ethernet] 


Apple cache 








2. The attacker is using the command-line utility 
arpspoof to poison the ARP entries through 
forged ARP reply packets: 





:~/Desktop/ # arospoof -1 eth -t 192.168.1.109 192.168.1.103 
0:¢:29:5d:a7:f7 d8:bo:2c:b9:53:ec 0806 42: arp reply 192.168.1.103 is-at 0:c:29:5d:a/:f7 
0:¢:29:5d:a7:f7 d8:bb:2c:b9:53:ec 0806 42: arp reply 192.168.1.103 is-at 0:¢:29:5d:a/:f7 
O:c:29:5d:a7:f7 d8:bb:2c:b9:53:ec 0806 42: arp reply 192.168.1.103 is-at 0:¢:29:5d:a/:f7 


0:¢:29:5d:a7:f7 d8:bb:2c:b9:53:ec 0806 42: arp reply 192.168.1.103 is-at 0:¢:29:5d:a7:f7 
0:¢:29:5d:a7:7 d8:bo:2c :b9:53:ec 0806 42: arp reply 192.168.1.103 is-at 0:¢:29:5d:a7:f7 


ARP reply packets sent to the Windows server on behalf of the Apple device 





| 
| 
| 
0:¢:29:5d:a7:f7 d8:bb:2c:b9:53:ec 0806 42: arp reply 192.168.1.103 is-at 0:¢:29:5d:a7:f7 
| 
| 





‘~/Desktop/ # arpspoof -1 ethd -t 192.168.1.103 192.168.1.109 
0:¢:29:5d:a7:f7 d8:bb:2c:b9:53:ec 0806 42: aro reply 192.168.1.109 is-at 0:¢:29:5d:a7:f7 
0:¢:29:5d:a7:f7 d8:bb:2c:b9:53:ec 0806 42: arp reply 192.168.1.109 is-at O:0:29:5dia/:f/ 
0:¢:29:5d:a7:f7 d8:bb:2c:b9:53:ec 0806 42: arp reply 192.168.1.109 is-at 0:¢:29:5d:a7: 7 
0:¢:29:5d:a7:f7 d8:bb:2c:b9:53:ec 0806 42: arp reply 192.168.1.109 is-at 0:¢:29;5d:a7:f7 
0:¢:29:5d:a7:f7 d8:bb:2c:b9:53:ec 0806 42: aro reply 192.168.1.109 is-at 0:¢:29:5d:a7: 7 
0:¢:29:5d:a7:f7 d8:bb:2c:b9:53:ec 0806 42: aro reply 192.168.1.109 is-at 0:¢:29:5d:a7:f7 
0:¢:29:5d:a7:f7 d8:bb:2c:b9:53:ec 0806 42; arp reply 192.168.1 


.109 is-at 0:¢:29:5dia/:f7 
0:¢:29:5d:a7:f7 d8:bb:2c:b9:53:ec 0806 42: arp reply 192.168.1.109 is-at O:¢:29:5d:a7: 7 


ARP reply packets sent to Apple device on behalf of the Windows server 


3. The traffic generated because of the preceding 
command looks like the following: 


23 3.019821 Inware b3icb: AR H 192,168. 1.1 t 00:0¢:29:5a:4 i 
24 5,016999000 Vmware Sd:a7:f7 Vmware b3scb:b6 ARP 42 192,168.1.103 18 at 00:0c:29:5d:a7sf7 


001262000 Viware Sd biaesb:S3iec AR 42 192,168,1,109 is at 00:00:29:Sd:a7s47 
| 


6 4,001992000 Vmware Sdsa7:f7  dBrbbs2esb0:53:¢c | ARP 42 192,168,1,109 18 at 00:0¢:29:5d:a7:17 


4. The packets sent from the Kali box forced the 
Apple and Windows machines to update their 
local ARP cache holding legit MAC addresses 
with the attacker's MAC address oe. oc: 29: 5p: a7: £7: 


¢\ Command Prompt 7 


A 


C:\Documents and Settings\Administrator>arp -a 


Interface: 192.168.1.109 --- @x18003 
Internet Address Physical Address Type 
192.168.1.1083 G0-Gc-29-5d-a?-f? dynamic 
192.168 .1.186 G@0-Gc-29-5d-a?-f? dynamic 


C:\Documents and Settings\Administrator> 





Poisoned window's cache 
Anonymous:~ NotFound$ arp -a 
? (172,16.136.1) at @:50:56:c:@:1 on vmnet1 ifscope permanent [ethernet] 
? (172.16.158.1) at @:50:56:c@:0:8 on vmnet8 ifscope permanent [ethernet] 
? (192,168.1.1) at d@:5b:a8:7:73:6c on en1 ifscope [ethernet] 
? (192,168.1.100) at f0:c1:f1:63:41:95 on enl ifscope [ethernet] 
? (192,168.1.106) at @:¢:29:5d:a7:f7 on enl ifscope [ethernet] 
? (192,168.1.109) at @:c:29:5d:a7:f7 on enl ifscope [ethernet] 


Poisoned Apple's cache 


5. Now all the traffic sent between the Apple and 
Windows boxes will be forwarded through Kali. 
For verification purposes, I turned off the 
Windows server machine and tried sending 
ICMP packets from the Apple box: 


Anonymous:~ NotFound$ ping 192.168.1.109 
PING 192.168.1.109 (192.168.1.109): 56 data bytes 
92 bytes from 192.168.1.106: Redirect Host(New addr: 192,168.1.109) 


Vr HL TOS Len ID Flg off TTL Pro cks Src Dst 
4 5 00 0054 8554 @ 0000 3f 01 7230 192.168.1.103 192.168.1.109 


The preceding output ensures that the packets are 
being forwarded through 192.168.1.10%, hence making our 
ARP poisoning attack a success. 


Create static ARP entries in critical machines to 
protect them from ARP spoofing attack; refer to the 
following screenshot for configuring static entries in a 
Windows box: 


C:\Documents and Settings\Administrator>arp -s 192.168.1.103 d8-bh-2c-h9-53-ec 


C:\Documents and Settings\Administrator arp -a 


Interface: 192.168.1.189 --- @x10003 
Internet Address Physical Address Type 
192.168.1.183 d8-bh-2c-h9-53-ec static 


Adding a static entry to local ARP cache 





Analysing brute force 
attacks 


You must be aware of the popularity of brute force 
attacks. The chances of success are not very high, but 
also it is not impossible due to the lack of complex 
passwords configured in corporate machines. Brute 
force attack is a way to guess login passwords 
configured in devices using a tool that automates 
password guessing process. 


To analyze malicious traffic of such nature, I will 
attempt to perform brute force over a preconfigured 
FTP service. FTP is used to transfer files efficiently 
with the assurance of integrity and confirmed delivery 
of the data in modern and critical network 
infrastructures. 


For testing and our analysis purposes, I have 
configured one FTP server at 192.168.1.108 over a Windows 
7 machine and the attacker is at IP 192.168.1.106 Over a 
Kali machine. 


Let's replicate and analyze the attack and normal FTP 
traffic pattern. Perform the following steps if you want 
to replicate it, but for educational purposes only: 


1. Configure the FTP client and the FTP server 
using whatever platform suits your needs best 


and make sure the link between the FTP server 
and the client is working. 

2. Now, first, we will try log in to the FTP server 
using a legitimate user and will record the 
traffic. Later, we will use the Follow TCP stream 
option in Wireshark to view the traffic details in 
easy-to-understand plain text format. 

3. Refer to the following screenshot where I 
initiated the connection between 
from FTP the client. I then supplied the wrong 
credentials in the first attempt, and then used 
the correct ones in the second attempt: 


@0e0e ®) Charit — root@kali: ~ — ssh — 80x25 





root@kali:~# nc -nv 192.168.1.108 21 

(UNKNOWN) [192.168.1.108] 21 (ftp) open 

220-FileZilla Server version 0.9.32 beta 

220-written by Tim Kosse (Tim.Kosse@gmx.de) 

22@ Please visit http://sourceforge.net/projects/filezilla/ 

user charit 

331 Password required for charit 

pass abc 

53@ Login or password incorrect! 

user charit 

331 Password required for charit 

pass charit 

23@ Logged on 

help 

214-The following commands are recognized: 
USER PASS QUIT CWD PWD PORT PASV- TYPE 
LIST REST CDUP RETR STOR’ SIZE ODELE- RMD 
MKD RNFR RNTO ABOR SYST NOOP APPE- WNLST 
MDTM XPWD XCUP XMKD XRMD- NOP EPSV_—_ EPRT 
AUTH ADAT PBSZ PROT FEAT MODE OPTS’ HELP 
ALLO MLST MLSD- SITE P@SW STRU- CLNT- MFMT 

214 Have a nice day. 

quit 

221 Goodbye 





4. After I successfully logged in, I issued the hetp 
command to view a list of commands available 
followed by a quit to terminate the connection. 


5. Wireshark captured the traffic between the FTP 
client and server; let's use the follow TCP 
stream option (right-click in list pane | follow | 
TCP Stream) to see the details: 


Stream Content 


220-FileZilla Server version 0.9.32 beta 

220-written by Tim Kosse (Tim. Kosse@gmx. de) 

220 Please visit http://sourceforge.net/projects/filezilla/ 

user charit 

331 Password required for charit 

pass abc 

530 Login or password incorrect! 

user charit 

331 Password required for charit 

pass charit 

230 Logged on 

help 

214-The following commands are recognized: 
USER PASS QUIT CWD PWD PORT PASV TYPE 
EDS: REST CDUP RETR STOR SIZE DELE RMD 
MKD RNFR RNTO ABOR SYST NOOP APPE NLST 
MDTM XPWD XCUP XMKD XRMD NOP EPSV EPRT 
AUTH ADAT PBSZ PROT FEAT MODE OPTS HELP 
ALLO MLST MLSD SITE P@SW STRU CLNT MFMT 

214 Have a nice day. 

quit 

221 Goodbye 


FTP assembled stream 


6. Now, as we have analyzed the normal traffic 
patterns, let's see what would malicious FTP 
packets (such as the brute force attack 
attempts) would look like. I am tuc-hydra to 


perform a brute force attack using a basic 
dictionary file. 

7. Issue the hydra -l <username> -P <password file> ftp: //<you 
target's IP address> COMMand. Refer to the following 


screenshot: 


MOMARANA:A# hydra -1 charit -P pass.txt ftp://192.168.1.103 
Hydra v7.6 (c)2013 by van Hauser/THC & David Maciejak - for legal purposes only 


Hydra (http://www.the.org/the-hydra) starting at 2015-09-12 18:16:00 
[DATA] 11 tasks, 1 server, 11 login tries (1:1/p:11), ~1 try per task 
[DATA] attacking service ftp on port 21 

(0 (GD) host: WOQRUSRRGS login: BABE password: GARR 

1 of 1 target successfully completed, 1 valid password found 

Hydra (http://www.the.org/the-hydra) finished at 2015-09-12 18:16:04 





8. The traffic generated was captured and, instead 
of displaying all the traffic, I have used a display 
filter ftp. request. command==Pass in order to view only 
packets pertaining to the FTP password 
command. The following screenshot shows what 
display filter I used to query malicious repetitive 
packets. 


Filter tp .emest command == "PASS 1 Expression... Cleat 


No. {Time 


60 1, 169458000 
61 1, 169645000 
62 1, 169830000 
63 1, 170013000 
128 3, 500600000 
131 3,501315000 
132 3,501529000 
133 3, 502078000 
134 3,502479000 
136 3,503548000 








Source 


192, 168. 1, 106 
192, 168, 1,10 
192, 168, 1, 10 
192, 168.1. 10 
192, 168.1, 10 
192, 168, 1,10 
192, 168.1, 10 
192, 168. 1,10 
192, 168, 1, 10 
192, 168.1, 10 











qaoomcaonrcncmnrnedad oO OF a oO 


Destination 











1,103 
1,103 
1,103 
1,103 
1,103 
1,103 
1,103 
1,103 
1,103 
1,103 


Save 


Protocol| Length’ Info 


2 
= 


= | q — | 
4 2) — 4 





4 
so 


FTP Brute Force attack traffic pattern 


76 Request: 
76 Request: 
79 Request 
7] Request 
76 Request: 
76 Request 
76 Request: 
78 Request: 
78 Request: 
76 Request: 





PASS 007 
PASS mo 
PASS charit 
PASS root 
PASS 123 
PASS efg 
PASS abc 
PASS admin 
PASS chris 
PASS mio 


9. It is easily identifiable that the preceding traffic 
is malicious due to the FTP pass command 


issued by a single IP over a very short period 


(refer to the time column). 


To identify such malicious or sensitive traffic, create a 


different coloring scheme (discussed in chapter 
3, Analysing Transport Layer Protocols TCP/UDP). 


Refer to the following screenshot: 


Filter 


List is processed in order until match is found 


Name 


String 





Coloring scheme for malicious traffic 





Inspecting malicious 
traffic (malware) 


Malware is one of the most common forms of client- 
side attacks in any network. The outcome of malware 
infections can be very damaging, ranging from denial 
of service attacks to remote code execution. Critical 
infrastructure industries such as Oil and Gas, Energy, 
Transport, and Manufacturing are one of the favorite 
targets for malware due to a lack of security controls 
and general awareness in place. Refer to the following 
screenshot, where we will try to replicate a malware- 
based infection in a lab: 


1. Client visits legitimate Website pareaeeta 


Compromised 
website 





— Malware location 
ee 
and C&C center 


IP :192,168,1.100 





Malware is capable of performing tasks once installed 
on the victim's machine, such as information 
disclosure, executing commands, and/or corrupting 
systems, even if the best security solutions are 
installed in the infrastructure. 


Follow these steps if you want to replicate the scenario 
in your own virtual lab: 


e You require three machines connected to the 
same LAN. Make sure they 
are able to ping to each other, to ensure 
connectivity. 


e On the IP address 192.168.1.106 Stays a legitimate 
website, which the 
client at IP 192.168.1.107 usually visits. However, this 
time, the client is not aware of the infection that 
causes redirection to another web server 
(assumption: the web server is compromised 
and taken over by the attacker). Refer to the 
following screenshot of the legitimate server: 


je 


eee 192.168.1.106 


C’ |) 192.168.1.106 





Charit's Apache Web Server 


Legitimate website 


e To simulate the redirection, I have configured 
my Apache server running On 192.168.1.106 to 
redirect HTTP requests to IP 192.168.1.100 and 
download the efg.exe from there. 


e When client visits the website running at 
192.168.1.106, it gets redirected to a new web server, 
which directly asks the client to run a file named 
efg.exe. Refer to the following screenshot: 


File Download - Security Warning 





Do you want to run or save this file? 
Name: efg.exe 
Type: Application, 1.25 MB 
From: 192.168,.1.100 


Bun 





While files from the Internet can be useful, this file type can 
potentially harm your computer. If you do not trust the source, do not 
run or save this software. What's the tisk? 


Client gets redirected to IP 192.168.1.100 and is asked to run the application. 


e The publisher of the application is not verified, 
so the client operating system is not able to 
verify it. This results in an unknown publisher 
error. Refer to the following screenshot: 


Internet Explorer - Security Warning 


The publisher could not be verified. Are you sure you want to run this 
software? 


Name: efg.exe 


Publisher: Unknown Publisher 


x 


Run 








This file does not have a valid digital signature that verifies its publisher, You 
should only run software from publishers you trust, How can I decide what 
software to run? 


Unknown publisher error 


e Once the client hits Run, the malware will be 


executed, thus creating a connection back to the 
command and control center (attacker). 


e We have a captured the traffic while the attack 
was in process. Let's take a look at it. Instead of 
showing just the traffic, I assembled the TCP 
stream first between the client and the 
legitimate server. 


e To understand the way our malware works, we 
need to look into the packet details. Refer to the 
following screenshot, which shows the 
assembled TCP stream: 


000 \\| Follow TCP Stream (top.stream eq 0) 


Stream Content 


GET / HTTP/1.1 

Accept; image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, */* 

Accept- Language: en-us 

UA-CPU; x86 

Accept-Encoding: gzip, deflate 

User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.2; SVL; .NET CLR 1.1.4322) 
Host: 192, 168, 1, 106 


Connection: Keep-Alive 


HTTP/1. 1 301 Moved Permanently 
Date; Mon, 14 Sep 2015 10:40:42 GMT 
Server; Apache/2.2.22 (Debian) 


Location: http: //192, 168.1, 100/efq, exe 
Vary: Accept-Encoding 

Content-Encoding: gzip 

Content-Length: 248 

Keep-Alive: timeout=5, max=100 

Connection; Keep-Alive 

Content-Type: text/html; charset=iso-8859-1 


cevnecunes Pa Ane. AU eee el.” Hel Hl nek eR CnnLionnel(— Gecnny lriter4 Innnt| Gr sar. peeel 
Bice via PRBS devadeasai™ rds 


peGhtaVisr ceric B se W a Grats DirnaUlisaee FOL Rese 
PesTO: Liles sealeeta aco Nemptatunmasneluasd igen Time ebem nena 


Entire conversation (846 bytes) Ms | 
“\ Find | F7Save As | Print |O ASC] O EBCDIC OHexDump OCArrays ® Raw 


1 Help Filter Out This Stream | \ Close 


TCP stream between the client and real (compromised) server 


e As is clearly visible, the client visits the web 
server, and the request is being forwarded with 
HTTP redirection to the new address 


http: //192.168.1.100/efg.exe 





e After a couple of packets were exchanged 
between the client and server, the client 
received a 200 ox status message, suggesting 
successful download of the executable 
application efg.exe 





LSS 6,429 108,100.07 == HTP ASBTP/L.1 00. aplacatuo/4 nso oat 


The following screenshot depicts the request sent by 
the client machine to download the executable from 
the new web address: 


@0@ \\ Follow TCP Stream (tcp.stream eq 1) 
Stream Content 


GET /efg.exe HTTP/1.1 4 
Recept, image/gif, amage/x-xbitmap, image/jpeg, image/pjpeg, */* ( 
Accept-Language: en-us 

UA-CPU; x86 


Accept-Encoding: gzip, deflate 

User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.2; SV1; .NET CLR 1.1.4322) 
Connection: Keep-Alive 

Host: 192, 168.1. 100 


HTTP/1.1 200 OK 

Date: Mon, 14 Sep 2015 10:40:40 GMT 

Server: Apache/2.2.12 (Win32) DAV/2 mod_ssl/2.2.12 OpenSSL/0.9.8k mod_autoindex_color 
PHP/5.3.0 mod_perl/2.0.4 Perl/v5, 10.0 
lLast-Modified: Mon, 14 Sep 2015 10:40:40 GMT 
ETag: W/"2a00000000f f0e- 142200-51fb4c11c8780" 
Accept-Ranges: bytes 

Content-Length: 1319424 

Keep-Alive: timeout=5, max=100 

Connection: Keep-Alive 

Content-Type: application/x-msdownload 


Wétstinnosooucug beonnoar Qiveverete vate revatere calecesoteterateicrarnietersfeveiat sie ratevainfeinnechereiainistarerely !,.L. !This 
aR ORES . a 
program cannot be run in DOS mode, . 


v 





& yr! 
Entire conversation (1309951 bytes) v | 
“. Find | [Save As | c= Print lo ASCIl O EBCDIC OHexDump OCArrays ® Raw 


Help (Filter Out This Stream | % Close 


Figure 7.20: Malware signature 


The cet request was initiated by the client in search of 
efg.exe, tO Which the server responded with a 200 « status 
message. Later, you can see the known malware 
signature starting with the characters mw followed by 
some random character. 


A quick Google search reveal that it is an executable 
file. Wikipedia states 16/32 bit DOS executable files 

can be identified by the letters w at the beginning of 
the file 


in ASCII. Refer to the following screenshot: 





DOS {cai 
Main articles: DOS Wiz executable and New Executable 


16-bit DOS MZ executable 
The original DOS executable file format, These can be identified by the letters "MZ" at the beginning of the file in ASCII 


Moving on with our investigation, let's export the efg.exe 
file. Perform the following steps to download the file: 


1. Go to File | Export Objects | HTTP: 


Activities Wireshark ¥ 


ial) Edit View Go Capture Analyze Statistics Telephony Wireless 
Open Ctri+O , 
Open Recent 


Merge... 


Import from Hex Dump... i Protoc 


Close Ctrl+W 
Save Ctrl+S 

Save As... Ctri+Shift+S 
File Set 

Export Specified Packets... 


Export Packet Dissections 


Export PDUs to File... 
Export SSL Session Keys... 
Export Objects 





Ctril+P 
Ctri+Q 
461 16.990107883 7.0.0.1 
467 16.990215635 ye ek 
468 16.990222676 7.0.0.1 
499 18.135472767 127.0.0.1 127.0.0.1 FTP 


The next screen would look as the following 
screenshot: 


@00@ \, Wireshark: HTTP object list 


Packet num |Hostname Content Type Size Filename 
8 192.168.1.106 text/html 315 bytes / 
22 192.168.1.106 text/html 315 bytes / 


Help ta Save As | fa Save All | & Cancel | 


Exporting HTTP objects 


2. Now, select the conversation that states the 
name of the file along with it and click on Save 
AS. 

3. An option is to upload this file to websites such 
aS http: //ww.virustotal.con, Which will scan the file 
through multiple antivirus programs. Refer to 
the following screenshot: 





Svirustotal 


VirusTotal is a free service that analyzes suspicious files and URLs and facilitates 
the quick detection of viruses, worms, trojans, and all kinds of malware. 


(\File @URL Q Search 


efg.exe Choose File 
Maximum file size: 128MB 


By clicking ‘Scan itl’, you consent to our Terms of Service and allow VirusTotal to 
share this file with the security community. See our Privacy Policy for details. 


Scan it! 





Uploadingefg.exeto virustotal.com 


4. Click Scan and wait for the results: 


D 


File name: 


total 


906703d07ef' ee085a498/cBbd7a621942e6178af87bfa1e81cd'1500416a1 bf 


efg.exe 


Detection ratio: 91/56 


a 
G0 G0 


31 out of 56 type of antivirus software detected the executable file as malicious. 


5. You can also manually examine the conversation 
between the infected client and the command 
and control center by looking at the hex dump. 
Refer to the following screenshot: 


Stream Content 


vurravey 


000A1978 
000A1988 
000A1998 
000A19A8 
000A19B8 
000A19C8 
000A19D8 
000A19E8 
Q00A19F8 
000A1A08 
000A1A18 
000A1A28 
000A1A38 
O00A1A48 
O00A1A58 





a 


46 69 6c 65 54 69 6d 65 
69 6c 65 54 69 6d 65 00 
65 49 6e 66 6f 72 6d 61 
Ge 64 6c 65 00 00 8d 03 
64 50 69 70 65 00 fb 01 
61 74 68 4e 61 6d 65 57 
75 72 72 65 6e 74 44 69 
00 00 d4 02 48 65 61 70 
53 65 74 45 6e 64 4f 66 
49 6d 70 65 72 73 6f 6e 
64 4f 6e 55 73 65 72 00 
54 6f 6b 65 Ge 50 72 69 
96 01 4c 6f 6f 6b 75 70 
65 56 61 6c 75 65 41 00 
00 00 00 00 00 00 00 00 


POSTE SS SSS SS ET CS HTS CeCe ve Conny 


54 6f 4c 6f 63 61 6c 46 FileTime ToLocalF 
ec 01 47 65 74 46 69 6c ileTime. ..GetFil 
74 69 6f Ge 42 79 48 61 eIlnforma tionByHa 
50 65 65 6b 4e 61 6d 65 ndle..., PeekName 
47 65 74 46 75 6c 6c 50 dPipe... GetFullP 
00 00 bf 01 47 65 74 43 athNameW ,...Getc 
72 65 63 74 6f 72 79 57 urrentOi rectoryW 
53 69 7a 65 00 00 53 04 ...,Heap Size..S, 
46 69 6c 65 00 00 73 01 SetEndOf File..s. 
61 74 65 4c 6f 67 67 65 Imperson ateLogge 
lf 00 41 64 6a 75 73 74 dOnUser. .. Adjust 
76 69 6c 65 67 65 73 00 TokenPri vileges. 
50 72 69 76 69 6c 65 67 .. Lookup Privileg 
00 00 00 00 00 00 00 00 eValueA. ......., 
00 00 00 00 00 00 00 00 


Hexdump in TCP stream dialog 


It seems that the attacker machine is issuing some 
command to gather information regarding the victim 
machine. The highlighted content on the right-hand 
side of the window states strings such aS cet Fite 
Information, Get full PC name, Get Current directory, Adjust token Privileges, 


and so on. 


Familiarity with such traffic patterns is critical, and it is 
advisable to set up filters capture filters in Wireshark 
to perform passive analysis to identify malicious traffic. 
For sure, IDS/IPS systems in your environment would 
be able to detect it automatically but in critical 
infrastructure networks (Oil and Gas, Energy, and so 
on), it is highly unlikely to have such security solutions 
deployed. In those scenarios, Wireshark is your best 
buddy and, most importantly, it comes for free!! 


Summary 


Use Wireshark to keep your network secure by 
defending against common forms of infiltration 
attempts. Analyzing the packets from a security 
perspective will give you a new insight into how to deal 
with malicious users. 


Activities such as port scanning, footprinting, and 
various active information gathering attempts are the 
basis of attacking methodologies that can be taken 
advantage of to bypass your security infrastructure. 
Create filters and signatures to identify malicious 
traffic patterns. 


Guessing passwords to gain unauthorized access is 
called a brute force attack. Through Wireshark, you 
can filter and identify such malicious forms of traffic. 


Wireshark can help you in analyzing malware behavior, 
and using the behavior analyzed, you would be able to 
create the necessary signatures for your IDS/IPS 
security solutions. 


The next chapter will enable network professionals to 
perform wireless packet analysis and teach them how 
to decrypt and read traffic from the air. 


Analyzing Traffic in Thin 
Air 

Most devices today are installed with wireless 
capabilities and it is critical to understand the 
structure and pattern of wireless traffic within your 
network. This chapter will assist in understanding the 


methodology and steps involved in performing wireless 
packet analysis. 


The following are the topics we will cover in this 
chapter: 


e Understanding IEEE 802.11 

e Modes in wireless communication 

e Capturing wireless traffic 

e Analyzing normal and unusual traffic patterns 


e Decrypting encrypted wireless traffic 


Wireless network traffic analysis is similar to wired 
network analysis; the objective of the topics discussed 
here is to learn about wireless technologies and 
protocol strengths and weaknesses, along with 
suspicious wireless traffic. 


Understanding IEEE 
$802.11 


At the Institute of Electrical and Electronics 
Engineers (IEEE), several groups of technical 
professionals as a committee are working on projects, 
and one of these is 802, which is responsible for 
developing Local Area Networks (LAN) standards. 
Specifically, 802.11 contains WLAN standards. 


There are a couple of 802.11 standards, for an outmost 
coverage of standards we will discuss the multiple of 
them such as 802.11b, 802.11a, 802.11g, and 

802.11n: 


e 802.11: Supports a network bandwidth of 1-2 
Mbps. This is 
the reason why many 802.11-compatible devices 
have become obsolete. 


e 802.11b: This specification uses a signaling 
frequency of 2.4 Ghz like the 802.11 standard. 
Technically, a maximum of 11 Mbit transmission 
rate can be achieved over a 2.4 Ghz band using 
b specification. 


The 802.11b band is divided into 14 overlapping 
channels, where every channel has 22 Mhz 


widths. In one instance, there can be a maximum 
of three non-overlapping channels operating at 
the same time. This space separation is 
necessary and required to let the channels 
operate individually. 


Most appliances, such as microwave, cordless 
phones, and so on. work over a 2.4 Ghz 
spectrum, which may cause significant 
interference and congestion in 802.11b WLAN 
packets transmission. 


802.11 a: This is based on Orthogonal 
Frequency Division Multiplexing (OFDM) 
that was released in 1999 and supports a 
maximum transmission rate up to 54 Mbps 5 
Ghz spectrums. This specification was developed 
as a second standard to 802.11 standards. It is 
commonly used in business environments; 
because of its high cost, the a specification is not 
best suited for home environments. There is no 
channel overlap that happens in 802.11a.A 
higher regulated frequency helps in preventing 
the interferences caused by devices that work 
on 2.4 Ghz spectrums. 


802.11g: Released in 2002, this specification 
combines the best features of 802.11a and 
802.11b. It uses a signaling frequency of 2.4 
Ghz, and bandwidth up to 54 Mbps. It also 
supports backward compatibility, which means 


that all 802.11g access points will support 
network adapters using 802.11b and vice versa. 


802.11n: To improve further on the range and 
the transfer rates, wireless specification n was 
introduced based on technology Multiple- 
Input Multiple-output (MIMO). The final 
version of this specification, released in 2007, 
stated a transfer rate up to 600 Mbps. It can be 
configured with 2.4 or 5 Ghz; it can use both 
frequencies at the same time, thus enabling 
backward compatibility with network adapters. 
A maximum of four antennas can be used with 
the MIMO technology. 


Various modes In 
wireless 
communications 


Wireless networks uses the Carrier Sense Multiple 
Access and Collision Avoidance (CSMA/CA) 
protocol to manage the stations sending data, where 
every host that wants to send data is supposed to listen 
to the channel first, that is, if it is free, then the host 
can go ahead and send the packet; if not, then the host 
has to wait for its turn. This is because the same 
medium is being shared by every host, thus avoiding 
collisions. 


The 802.11 architecture is composed of several 
components such as a station (STA), a wireless 
Access Point (AP), Basic Service Set (BSS), 
Extended Service Set (ESS), Independent Basic 
service set (IBSS), and Distribution System (DS). 


There are four common modes of association between 
the STA and the AP 
which are as follows: 


e Infrastructure/managed mode: A wireless 
network where a wireless client establishes a 
connection with an access point to access data 
and network resources. An AP is defined with a 


Service Set Identifier (SSID), which is the 
access point's name used for identification 
purposes within a certain range (for security 
reasons, sometimes, broadcasting an SSID can 
be disabled, which will prevent your wireless 
network from being discovered). For example, 
when we scan for available nearby Wi-Fi 
networks around, we will be shown multiple 
network names to choose from. Another useful 
term to know is Base Service Set Identifier 
(BSSID), that is, the access point's MAC 
address. 


By default, every access point is supposed to 
broadcast the SSID and transmit a beacon frame 
10 times in a second to let clients know that AP is 
ready to accept connections. Refer to the 
following diagram: 


= 


es 
Client Wireless Access 
Point 











e Ad Hoc mode: In Ad Hoc mode, a peer-to-peer 
network is formed where two clients connect to 
each other. The packets sent and received by 


the wireless clients are not relayed to the access 
point. Refer to the following diagram: 


= im 


- Wireless Client 
2 








Wireless Client 
1 


e Master mode: When the NIC (network 
interface card) adapter is capable to act as an 
access point for clients through usage of special 
drivers then it becomes a master node. Modern 
operating systems and hardware are enabled 
with such a feature, where the host device can 
act as an access point by sharing its wired 
connection. Refer to the following diagram: 


= 


i —— 








Wireless Client Wireless Client 
working as AP 


e Monitor mode: This mode enables a network 
adapter to listen to wireless network traffic; 
when the monitor mode is activated, your device 


will stop transmitting and receiving any packets 
and it will just sniff live traffic in a passive way. 
In short, wireshark running with an interface 
enabled with monitor mode can sniff traffic 
without being a part of the network. This mode 
is often termed as the Radio Frequency 
Monitor Mode (RFMON). Refer to the 
following diagram: 





Wireless Client 
Wireless Access 
Point 





Wireless Client with 
monitor mode enabled 


Usual and unusual 
wireless traffic 


In 2003, Wi-Fi Protected Access (WPA) was 
launched by Wi-Fi Alliance as a measure to make 
WLAN communication stronger than the previous 
protocol, WEP. The key size used by WEP is 40/104 
bits, whereas WPA uses a key size of 256 bits and also 
facilitates integrity checks. In WEP the traditional CRC 
was implemented, but WPA introduced, the popular 
Michael 64-bit Message integrity check (MIC). 


WPA uses the RC4 algorithm to build a session based 
on dynamic encryption keys (you would never end up 
using the same key pair between two hosts). Refer to 
the following illustration of how the cipher text is 
formed that is transmitted over the medium: 


IV +KEY Rcd | > | of of af un 
LL, gd Key stream 


Seed ht a. 1 0 0 





Cipher Text 


The process starts by appending the IV and the 
dynamically generated 256-bit key. Followed by 


encryption using RC4 algorithm, the resulting 
encrypted key stream is then appended with the data 
and voila! We have the final cipher text. 


Refer to the following diagram depicting the 
authentication process in WPA: 


{Four Way Handshake] 


Probe request/response, 
mmm Autfientication/AgsOclation Request-Response 


PSK Formed PSK Formed | 
AP nonce 


Calculate PTK 


Calculate PTK 
{and GTK if 


required) 


Install Kevs 


Install Keys 





The following is a summary of steps involved for the 
preceding diagram: 


1. First, the Master Key Exchange (PSK) takes 
place, followed by transmission of a nonce value 


to STA (initiation of connection). 

2. The STA will use the AP's nonce value and its 
own nonce to calculate the Pairwise Transient 
Key (PTK) to send along with the Pre-Shared 
Key (PSK) established in the previous step. The 
resulting value will be sent to the AP to calculate 
the PTK and append the MIC with the Receive 
Sequence Counter (RSC). 

3. Now, the STA will first verify the MIC in the 
message to ensure the integrity and then install 
the keys. 


4. Aresponse will be sent to the AP regarding the 
status. If the status shows success, the AP then 
installs the same keys (dynamic keys) that will 
be used in further communication. 


The following screenshot depicts the four 
authentication packets involved in a successful WPA 
Enterprise handshake process: 


Fiterfapol + {Expression Clear Apply Save 








No. Time Source Destination {Protocol} Length| Info 
257 8. 730625000 Zte_07: 73: 6c Apple_b9:53:ec  EAPOL 173 Key (Message 1 of 4) 
259 8, 733391000 Apple_b9:53:;ec Zte_07:73:6c —- EAPOL 197 Key (Message 2 of 4) 
265 8, 736180000 Zte_07:73:6¢ Apple_b9:53:ec  EAPOL 203 Key (Message 3 of 4) 
267 8, 737817000 Apple_b9:53:ec  Zte_07:73:6c EAPOL 173 Key (Message 2 of 4) 


> Frame 257: 173 bytes on wire (1384 bits), 173 bytes captured (1384 bits) on interface 0 
> Radiotap Header vO, Length 36 
> IEEE 802.11 QoS Data, Flags: ......F.C 
Vv 802. 1X Authentication 
Version: 802. 1X-2001 (1) 
Type: Key (3) 
Length: 95 
Key Descriptor Type: EAPOL WPA Key (254) 
> Key Information: 0x008a 
Key Length: 16 
Replay Counter: 0 
WPA Key Nonce; 5ec313cec318318d18df8df fdffb0047fb8a47518aea5152, . . 
Key IV; 00000000000000000000000000000000 
WPA Key RSC; 0000000000000000 
WPA Key ID; 0000000000000000 
WPA Key MIC; 00000000000000000000000000000000 
WPA Key Data Length: 0 





Getting into more detail, let's observe the flags 
involved in all of the preceding four authentication 
packets in the handshake process: 


7 802, 1X Authentication 
Version; 802, 1X-2001 (1) 
Type: Key (3) Packet 1 
Length: 95 
Key Descriptor Type: EAPOL WPA Key (254) 

¥ Key Information; 0x008a 
sone seen ene (010 = Key Descriptor Version; AES 
vvoee Live = Key Types Pairwise Key 
00... = Key Index: 0 
verve Dee core = Installs Not set 
revere deve core = Key ACK: Set 
riiO vice seve = Key MIC: Not set 
sscoee vere = Secures Not set 

seve core S Error; Not set 

cove veee = Request; Not set 

vive ceva Encrypted Key Data: Not set 

i iss ssi 5 SMK Message: Not set 

7 802. 1X Authentication 
Version; 802, 1X+2001 (1) 
Type: Key (3) Packet 3 
Length: 125 
Key Descriptor Type; EAPOL WPA Key (254) 

Y Key Information: Ox0lca 
cent anne ange (010 = Key Descriptor Version; AES 
sveee divs = Key Type: Pairwise Key 
00 .,,, = Key Index; 0 
vevbes coos = Installs Set 
coves Live cree = Key ACK! Set 
veel iccce cece = Key MIC: Set 
voce coos 2 Secures Not set 
voce veoe S Error! Not set 
voveee veee = Requests Not set 
‘overs veee ® Encrypted Key Data; Not set 
svire coos ® SUK Message: Not set 


cove Gans 
1108 cone 


Y 802, 1X Authentication 
Version; 802, 1X-2001 (1) 
Type: Key (3) Packet 2 
Length: 119 
Key Descriptor Type: EAPOL WPA Key (254) 

Y Key Information; Ox0l0a 
vy vere cove O10 = Key Descriptor Version; AES 
seve deve = Key Type: Pairwise Key 
00 ..., = Key Index: 6 
1 O.. ..0. 2 Install: Not set 
ce ceee Ores sees 2 Key ACK: Not set 
cdbvcce von = Key MIC: Set 
reve cove # Secure; Not set 
rove vere = Error, Not set 
sveve voee = Request: Not set 
. soc coos = Encrypted Key Data: Not set 
ve vere vee = SNK Message: Not set 


7 802, 1X Authentication 


Version; 802, 1X-2001 (1) 
Type: Key (3) Packet 4 
Length: 95 
Key Descriptor Type: EAPOL WPA Key (254) 
Y Key Information; Ox010a 
seen auee cunt 010 = Key Descriptor Version; AES 
viv vece Lice = Key Type: Pairwise Key 
00... = Key Index: 0 
ve vere Dee coos = Installs: Not set 
rere cece Duce coos # Key ACK: Not set 
cedivee sees = Key MIC: Set 
sree voee & Secures Not set 
sve coos S Errors Not set 
Qi sree sees = Request: Not set 
vive veee coon ® Encrypted Key Data; Not set 
scree cece & SMK Message: Not set 





Here is the description of the preceding authentication 


packets: 


e Packet 1: The pairwise master key (pre-shared 
key) and the ax bit are set (because of the 
association request/response exchanged 
earlier), which is sent by the AP to the STA to 
initiate the connection along with the nonce 
value chosen randomly. 


e Packet 2: The pairwise master key and the mic 
flag is set, which the STA sent to the AP to 
acknowledge the request, along with its own 
nonce value appended to the AP's nonce and the 
utc for integrity check. 


e Packet 3: The pairwise master key, install, key 
ack, and mic flags are set, which AP sent to STA. 
Next, the STA will fulfill the challenge in order to 
get authenticated. 


e Packet 4: The pairwise master key and the mic 
flag are set, which 
the STA sends to AP to complete the connection 
process. 


Based on our understanding of a successful 
authentication process, now let's try to observe the 
packet pattern in the case of unsuccessful 
authentication. The only difference in this scenario is 
that the STA is not aware of the pre-shared key. 


Refer to the following screenshot: 


tered v apes, Clear Apply Save 


Destination Protocol| Length Info 
Tte.07:73:6¢ Apple 63:41:95 EAPOL 173 Key (Message 1 of 4) 

















132 6, 386204000 


141 6, 393312000 Apple 63:41:95 2te.07:73:6¢ —EAPOL 199 Key (Message 2 of 4) 
155 7, 392817000 Tte.07:73;6¢ + Apple63:41:95 —EAPOL 173 Key (Message 1 of 4) 
157 7, 395444000 Apple 63:41:95 2te.07:73;6¢ + EAPOL 199 Key (Message 2 of 4) 
169 8, 401006000 Tte.07:73:6¢ Apple 63:41:95 — EAPOL 173 Key (Message 1 of 4) 
171 8, 403683000 Apple.63:41:95 Zte.07:73:6¢ + EAPOL 199 Key (Message 2 of 4) 
182 9, 409178000 Tte.07:73:6¢ Apple 63:41:95  EAPOL 173 Key (Message 1 of 4) 
164 9, 411794000 Apple 63:41:95  2te.07:73:6¢  EAPOL 199 Key (Message 2 of 4) 


4 


saddaad 


) Frame 132: 173 bytes on wire (1384 bits), 173 bytes captured (1384 bits) on interface 0 
 Radiotap Header vO, Length 36 
) TEEE 802.11 QoS Data, Flags: ......F.C 
V 802,1X Authentication 
Version; 802,1X-200 (1) 
Type: Key (3) 
Length: 95 
Key Descriptor Type: EAPOL WPA Key (254) 
) Key Information; Ox008a 
Key Length: 16 
Replay Counter; 0 
WPA Key Nonce; 8d2896bd4a12509584af2578d43a5e2cOe9b74db592636c8, 
Key IV; 00000000000000000000000000000000 
WPA Key RSC; 0000000000000000 
WPA Key 1D; 0000000000000000 
WPA Key MIC; O0000000000000000000000000000000 
WPA Key Data Length: 0 


WPA Failed authentication 


The preceding screenshot depicts the chain of packets 
transmitted between the STA and AP due to an 
incorrect pre-shared key being sent by STA. These 
packets may be witnessed in an event of a brute force 
attack against the AP 


WPA Enterprise 


In order to standardize and harden the authentication 
process and introduce a few elements of accountability 
and non-repudiation, WPA offers the configuration of 
an external server to validate and authorize STAs. This 
centralized authentication and validation unit is 
termed as a RADIUS/TACACS server. Before the four- 
way handshake takes place, the RADIUS server and 
the access point are supposed to go through a MSK. 
Let's have a look at the following diagram: 


RADIUS 







Master Key Exchange 


PMK 


Handshake 


Post the exchange of the master key, the pairwise 
master key is created and passed on to the AP which 
will further complete the four-way handshake process. 


As a part of graceful termination, the wireless stations 
use disassociation packets in order to notify the access 
point that the STA is now going offline and the 
resources allocated can be released. The following 
screenshot lists the packets observed during the 
disassociation phase: 


Apple b9:53:ec Zte07:73:6¢ 





> Frame 318; 66 bytes on wire (528 bits), 66 bytes captured (528 bits) on interface 0 
b Radiotap Header vO, Length 36 
Vv IEEE 802,11 Disassociate, Flags: ........ C 
Type/Subtype: Disassociate (0x000a) 
> Frame Control Field: 0xa000 
000 0001 0011 1010 = Duration; 314 microseconds 
Receiver address; Zte_07:73:6c (dO: 5b: a8: 07:73; 6c) 
Destination address: Zte_07:73:6c (d0;5b:a8:07:73:6c) 
Transmitter address; Apple_b9:53:ec (d8:bb;2c:b9; 53; ec) 
Source address: Apple_b9:53:ec (d8:bb:2c:b9; 53: ec) 
BSS Id: Zte_07:73:6c (dO: 5b: a8: 07:73: 6c) 
Fragment number; 0 
Sequence number; 1979 
> Frame check sequence: 0x989e716b [correct] 
Vv 


v Fixed parameters (2 bytes) 
Reason code; Disassociated because sending STA is leaving (or has left) BSS (00000) | 2 


The disassociation packet 


The wireless stations use the deauthentication frames to 
notify the access point that the STA is leaving. As we 
can observe in the preceding screenshot, first, the STA 
sends a disassociation frame and receives ac (318,319) from 
AP. 


There can be several scenarios where an wireless 
client would send a disassociation frame. Refer to the 
following screenshot to understand this: 






Apple_b9:53:ec = Zte_07:73:6c 
468 21, 434398000 Apple_b9:53: ec 





prrvrrr 


b Frame 467: 66 bytes on wire (528 bits), 66 bytes captured (528 bits) on interface 0 

> Radiotap Header vO, Length 36 

Vv IEEE 802.11 Deauthentication, Flags: ........ ¢ 
Type/Subtype: Deauthentication (0x000c) 

> Frame Control Field: oxcd0O. 
000 0001 0011 1010 = Duration: 314 microseconds 
Receiver address: Zte_07:73:6c (d0:5b:a8: 07:73: 6c) 
Destination address: Zte_07:73:6c (d0:5b:a8:07: 73: 6c) 
Transmitter address: Apple_b9:53:ec (d8:bb:2c:b9:53:ec) 
Source address: Apple_b9:53:ec (d8:bb:2c:b9: 53: ec) 
BSS Id: Zte_07:73:6c (dO: 5b: a8: 07:73: 6c) 
Fragment number: 0 
Sequence number; 1986 

> Frame check sequence: 0x9171b952 [correct] 


v Fixed parameters (2 bytes) 
Reason code: Previous authentication no longer valid (0x0002) | 2 | 


The deauthentication packet 





Vv 


In the preceding list of packets, first, the STA sends a 
deauthentication frame to the access point, which gets 
acknowledged in the next packets (467,468). 


less 


C 


ing wire 


Wireshark also facilitates decryption of wireless traffic 


through embedding a pre-shared key under the 
802.11 protocol section. The following screenshot 
depicts normal wireless traffic being sniffed from a 


nearby access point: 
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In order to decrypt the preceding listed packets, we 
need to configure the IEEE 802.11 section as follows: 


1. Go to Edit | Preferences, expand the Protocol 
section, select IEEE 802.11 and configure it as 
follows: 


Wireshark « Preferences 





HPFEEDS a 
HSMS 

HSRP ¥ Reassemble fragmented 802.11 datagrams 

HTTP 

HTTP2 Ignore vendor-specific HT elements 

IAPP 

IAX2 V Call subdissector for retransmitted 802.11 frames 
IB 
ICAP 
ad V Validate the FCS checksum if possible 
cP Ignore the Protection bit 

ICQ ®) No 


IEEE 802.11 


IEEE 802.15.4 Yes - without IV 
IEEE 802.1AH Yes - with IV 
IFCP 

ILP V Enable decryption 
IMAP 

IME Decryption keys Edit... 
INAP 

Infiniband SDP 

Interlink 

IPDC 

IPDR/SP 

iPerf2 

IPM > 


IEEE 802.11 wireless LAN 


Assume packets have FCS 


Cancel Help 


2. Click on the Edit button next to Decryption Keys. 

3. Click on New and add the WEP/WPA key to 
enable decryption. After all the changes have 
been made, click on OK: 


HPFEEDS 4 


HSMS ; 
en WEP and WPA Decryption Keys 


HTTP 
HTTP2 Key type Key 
|APP 





ICQ 7 
IEEE 802.15.4 
IEEE 802.1AH 
iFCP 

ILP 

IMAP 

IMF 

INAP 
Infiniband SDP 
Interlink 

IPDC 

IPDR/SP 


iPerf2 
IPMI RS Rem 


4 » 


pa 





Now you will be shown the decrypted traffic as follows: 


No, Time | Source 


Destination 


Protocol] Length} Info 


30, 101892 MS-NLB-PhysServer10_Tp-LinkT 2a:84:4e 


4 4,038400 192, 168.0, 100 


192, 168, 0,1 


6 4.141316 MS-NLB-PhysServer-10_ Tp-LinkT 2a; 84; 4e 


7 5,038400 192, 168, 0, 100 


192, 168,0.1 


9 5,141316 MS-NLB-PhysServer-10_Tp-LinkT 24:84: 4e 


10 6,039426 192, 168, 0, 100 


192, 168.0,1 


12 6, 142340 MS-NLB-PhysServer-10_Tp-LinkT_2a;84; 4e 


13 8.039426 192, 168, 0, 100 








192, 168.0, 1 








15 8, 143876 MS-NLB-PhysServer-10_Tp-LinkT 2a:84;4e 


16 12,042496 192, 168, 0, 100 


192, 168,0,1 


802, 11 
DNS 


802, 11 
DNS 


802,11 
DNS 


802,11 
DNS 


802,11 
DNS 


26 QoS NuLL function (No data 
111 Standard query Oxeed6 A ct 


26 QoS Null function (No data 
111 Standard query Oxeed6 A ct 


26 QoS Null function (No data 
111 Standard query Oxeed6 A ct 





26 QoS Null function (No data 
111 Standard query Oxeed6 A ct 














26 QoS NuLL function (No data 
111 Standard query Oxeed6 A ct 


WLAN traffic after decryption 


, 9N=2642, FN=0, Flags=,..P,.,7 


, 9N=2643, FN=0, Flags=,..P,., 


, SN=2644, FN=0, Flags=,,.P,..T 


, 9N=2645, FN=0, Flags=,,.P,.,7 





SN=2641, FN=0, Flags=,,.P.,.T 
dl, windowsupdate, com 


dl, windowsupdate, com 





dl. windowsupdate, com 


dl. windowsupdate, com 








dL, windowsupdate, com 


Summary 


The IEEE 802.11 standard works over radio 
frequencies for communication purposes. CSMA/CD 
facilitates the collision-free environment required for a 
high-performance wireless networks. 


There are commonly three types of frames observed 
while doing wireless traffic analysis: management, 
control, and data frames. Management frames control 
the establishment of the connection, control frames 
manage the transmission of packets, and data frames 
consist of the actual data. 


Enterprise authentication protocol (EAP) in 
LAN becomes EAPOL, which is used in 802.11 
infrastructures (RADIUS/ AAA) for the exchange of 
master keys. 


EAP is used to let the exchange of master keys take 
place. As defined in RFC 3748, EAP is an 
authentication framework that supports multiple kinds 
of authentication methods, and to execute EAP you do 
not require an IP because it runs over a data-link layer. 


Access points broadcast beacon frames that wireless 
clients listen for. Also, wireless clients may send a 
probe request to get connected to the access point, 
followed by authentication carried out by the access 
point or third-party authentication service. 





Mastering the Advanced 
Features of Wireshark 


In this chapter, we will look under the hood of the 
advanced options available in Wireshark and work with 
a command-line version of packet sniffer. Here, we will 
be covering the following topics: 


e Analyzing the network using the Statistics menu 
e Using TCP Stream 
e Using the Protocol Hierarchy Option 


e Using command-line tools for protocol analysis 


With Wireshark, a variety of statistics about the 
network packets, protocols and endpoints can be 
viewed and analyzed. Understanding and awareness of 
advanced features such as protocol hierarchy, 
conversations, endpoints, and so on, assists in 
performing tasks pertaining to troubleshooting, 
optimizing, and forensics activity through viewing and 
analyzing network related information specifics in 
detail. 


The Statistics menu 


Wireshark provides various tools that assist in 
collecting network stats, which help users in analyzing 
information ranging from general information to 
specific protocol-related information. 


Using the Statistics 
menu 


Details with respect to the packets captured, filters 
applied, marked packets, and various other stats can 
be checked in the Statistics menu; refer to the 
following screenshot for reference (Source: http: //wireshar 
k.org): 





4 odd-http.pcap 


4060 (ERE Yes 











No, Time Source | 
r 10,00000@ 200.121.1131 : 
3 0,025738 200.121.1.131 =: 


40,025749 172.16.0,122 





7 0.102939 200,121,1.131 


9 0.128285 200.121.1,131 


11 0.154162 200,121,1,131 





13 0.179906 200.121,1.131 | 
Frame 1: 1454 bytes on wire (1163; 
Ethernet II, Src: Vmware c0:00:01 


Internet Protocol Version 4, Src: 
Transmission Control Protocol, Sri 
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Endpoints 

Packet Lengths 

(0 Graph 


Service Response Time > H 
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Packets: 3083 * Displayed: 3083 (100.0%) * Load time: 0:0,100 |) Profle: Default 





Protocol Hierarchy 


The Protocol Hierarchy window provides details 
pertaining to the distribution of protocols seen in 
network traffic. Each of the rows represents stats 
pertaining to one protocol; refer to the following 
screenshot: 


006 \, Wireshark: Protocol Hierarchy Statistics 
Display filter: none 





End Mbit/s 





Protocol 


Vv 





7 Ethernet HiBs% = 1720 4% 771877 0.000 0 0 0,000 
¥ Internet Protocol Version 4 48. BR 1681 fio % 769855 0,000 0 0 0.000 
¥ Transmission Control Protocol E635 1125 fb.48 % 448453 0,000 651 190306 0.000 
Data [7.74%  267]6.95% 105716 0.000 267 105716 —0.000 

» Secure Sockets Layer ] 5.16%  178]8.88% 135024 0.000 171 127524 0.000 
Secure Sockets Layer 0.20 % 70.49% 7500 0.000 7 7500 ~—0,000 
Malformed Packet 0.44 % 15, 0,80% 12152 0,000 15 12152 0,000 

v Hypertext Transfer Protocol 0,41 % 14, 0,35% 5255 0,000 9 2480 0,000 
Media Type 0.03 % 10.01% 159 0,000 1 159 0,000 
Line-based text data 0,09 % 30.10% 1501 0.000 31501 ~——0,000 
eXtensible Markup Language 0,03 % 10.07% 1115 0,000 1 1115 ~~ 0,000 

¥ User Datagram Protocol hs.s2% 535 1.03 % 319932 0,000 0 0 0,000 
Data 0.29 % 10, 0,03% 460 0,000 10 = 460 ~—0,000 
NetBlOS Name Service 0,09 % 30.02% 276 0,000 3-276 ~——«0,000 
Domain Name Service | 3.92% 135 0,90% 13741 0,000 135 13741 ~—(0~,000 

QUIC (Quick UDP Internet Connections) 11.22% 387 §10.08% 305455 0.000 387 305455 (0,000 
Internet Control Message Protocol 0.61 % 21/0.10% 1470 0,000 21.1470 0,000 

¥ Internet Protocol Version 6 0,26 % 9 0.05 % 762 0,000 0 0 — 0,000 
Transmission Control Protocol 0,09 % 30.02% 270 0,000 3 270 ~— 0,000, 


. { 
Veh Ma huw bene me Muwhe wel if nwnw ri annnw Ann A AANA la ann nA ANA 


Help XM Close | 


Protocol Hierarchy window 





If you want to check the protocol distribution for a 
specific host, then before you open the Protocol 
Hierarchy window, apply a Display filter, for example, 
ip.addr==172.20.10.1. Now, when you open the hierarchy 
window again the filter will be visible at the top of the 
Protocol Hierarchy window just below the title bar: 


\, Wireshark: Protocol Hierarchy Statistics 


Display filter: ip.addr==172.20.10.1 


e00e 
Protocol 
S 
v Ethernet Bo 
v Internet Protocol Version 4 BRO % 
¥ User Datagram Protocol | 447003 
Data | 3.05 % 
Domain Name Service | 4103 
Internet Control Message Protocol | 5.79% 
v Raw packet data Bm % 
v Internet Protocol Version 4 BIYH90 % 
v User Datagram Protocol | 447503 
Data | 3,05 % 
Domain Name Service By 16% 
Internet Control Message Protocol | 5.79% 


SHelp 


% Packets |Packets |% Bytes 
100.00 % 


164 IEEE % 


164 BER 9 % 


145 (ZEB? % 


10 1.60 % 


135 7 % 


19| 4.62 % 


164 Tp % 


164 EEGHO1 % 


145 (p31 % 


10 1.11% 


135 (EBN20 % 


19| 3.70% 


Bytes |Mbit/s |End Packets |End Bytes |End Mbit/s 


15531 0.000 0 0 0.000 
15531 0.000 0 0 0.000 
14201 0.000 0 0 0.000 
460 0.000 10 460 0.000 
13741 0.000 135 13741 0.000 
1330 0.000 19 1330 0.000 
13235 0.000 0 0 0.000 
13235 0.000 0 0 0.000 
12171 0.000 0 0 0.000 
320 0.000 10 320 0.000 
11851 0.000 135 11851 0.000 
1064 0.000 19 1064 0.000 
% Close | 





Protocol Hierarchy window after applying display filter 


Using the Protocol Hierarchy window, display filters 
can be generated and applied too. Just right-click on 
the protocol you wish to use and then choose the 
desired option, as shown in the following screenshot: 





Apply as Filter 
Prepare a Filter 
Find Frame 
Colorize Procedure 


Selected 

Not Selected 

.. and Selected 
.. or Selected 


.. and not Selected 
.. or not Selected 


The Protocol Hierarchy window will be worth checking 
in an event where the malware-related activity needs 





Conversations 


To analyze network communication pertaining to two 
specific endpoints, Conversation option can be used 
(available under Statistics menu). To access it, click on 
Statistics | Conversations. The window will list the 
network layers to assess at the top, and endpoint 
addresses (IP or MAC) in rows: 


e0e \\ Conversations: sample2,pcapng 

Ethernet: 3° bre Chon! [00 [tPv4: 29|tPv6: 2{ipx| x1 |uce|asve|scte| rep: 27] roken & no for: 75 use ivan 
Ethernet Conversations 

Address A Address B Packets |Bytes |PacketsA-B |BytesA+B |PacketsA+B | Bytes A+B 

Apple_b9:53:ec Broadcast 3 =. 276 3 276 0 

4a:74:6e:ba:d0:64 — Broadcast 30 1260 30 1 260 0 





Name resolution O Limit to display filter 


S2Help | Copy Follow St a | Graph AB | raph ArB | % Close | 


Conversations window 


For instance, if we need to identify the endpoint which 
is generating the most traffic in the network, go to 
the [Pv4 tab and sort the Bytes column in descending 
order: 


006 \, Conversations; sample2.poapng 


Ethene: 3] ve Chae 00) v4: 29]: 2} uc] eave |scre| ter 27} olen Ring [ume ms] sea 
IPv4 Conversations 
Address A AddressB | Packets Bytes /PacketsA-B |BytesA-B |PacketsAHB {Bytes AKB 


172.20,10.7 = 216.58,220.46 430 256 350 204 27 884 226 = 228 46) 


172.20,10.1 172.20,10,7 366 31 160 17217970 1941319 
172.20,107 = 173.194.126.120 364 296 096 144-28 864 220 26723 
4.231,136,106 — 172,20,10,7 2/6 220 766 138 212544 118 822, 
172.20,10.7 == 216.58,196,99 186 128 678 8214340 10411433 
172.20.10,7 = 216.58,196.110 130 83634 8 13.692 2 69.94, 


Busiest devices 


In the preceding screenshot, the first row depicts how 
many packets and bytes have been sent and received 
by the endpoints. For creating a display filter through 
conversation dialog, right-click on a row and then 
create the desired expression. I chose the first option, 
A<->B, which would only display packets associated 
with Address A and Address B: 
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The newly created filter expression will be shown in 
the Display Filter dialog, as shown in the following 
screenshot: 





Filter: |ip.addr==17,143.162,208 && ip.addr==172.. _+ | Expression... Clear 4\ Save 


The Conversations dialog assists in collecting and 
analyzing details in the granular form associated with 
specific endpoints, which comes in handy while 
troubleshooting and auditing networking 
infrastructures. 


Endpoints 


Devices that communicate over a network are referred 
to as endpoints. Endpoints in a local area network 
communicate using a physical address that is MAC 
address. In a switched environment, communication 
takes place using physical addresses; switches store 
MAC address table and work on layer 2 of TCP/IP 
model. 


Let's say, for example, that we are observing the heavy 
flow of network traffic from certain endpoints, which is 
kind of unusual based on our playbook data (usual 
traffic pattern). To identify the exact endpoint from 
which the superfluous flow of network traffic is 
generated, the Endpoints dialog comes to the rescue. 
To access it, click the Endpoints option under 

the Statistics menu. The Endpoints windows look quite 
like the Conversations windows we observed 
previously. 


By default, the Ethernet tab will be shown (which lists 
the layer-2 MAC address) in most cases. Along with the 
protocol, you must observe a number that states the 
number of endpoints captured for that specific 
protocol. In our case, we are seeing 3, and the same 
number of rows are visible in the Main pane. 


In the Main pane, many more specific details can be 
seen for every endpoint, such 
as the total number of packets transferred, total 


number of bytes transferred, and total bytes and 
packets received and transmitted for an individual 
endpoint: 


e00e \} Endpoints: sample2.pcapng 
Ethernet: 3 [F001 |tPv4: 32 |1Pv6: 3|\px|)x74 [vce |asve|scre| ter: 49| ng |upP: 90|se win 
Ethernet Endpoints 
Address Packets |Bytes |Tx Packets |Tx Bytes |Rx Packets | Rx Bytes 
Apple_b9:53:ec 1690 770617 870 133603 820 637 014 


Broadcast 33-1536 0 0 33 1 536 





Name resolution O Limit to display filter 
Help Copy | OM"aj | X Close | 


Endpoints window 


Now, if you want to analyze other protocols, then 
simply click on any tab of your choice. I clicked on the 
IPv4 tab and sorted the main pane using the Packets 
column, as shown in the following screenshot. 


By just looking at the Endpoints dialog, I can now 
easily figure out that the most data was transferred 
from IP 172.20.10.7. This could be one single IP talking to 
some server or, more likely, a server talking to multiple 
machines on our network at a moderate rate: 


868 |\, Endpoints: sample2 poapng 


Ethernet: 3 ibre ( han )) IPv4: 32| v6 3) |) AlN P| sve |e: 4a| Token ‘yo UDP: 90 [uss AN 
IPv4 Endpoints 


Address 





Packets « Rx Packets Latitude Longitude 
172.20.10,7 3404 1 518 822 1752 255718 1652 1263 104 : 
17.143.162.208 900 229 312 366 172714 534 56598 - 
216.58.220.46 430 256 350 226 = 228 466 204 = 27884 - 
172.20.10.1 366 31160 172 17970 194 13190 - 
173.194.126.120 364 296 096 220 = 267 232 144 28 864 - 
54.231.136.106 276 220 766 158 212 544 118 = 8222 - 


216.58.196,99 186 128 678 104 114338 82 14340 - 
216.58.196.110 130 83 634 2 69942 $8 13 692 - 
17.178.104.39 114 45.990 229624 62 16 366 - 
216.58.196,97 104 34162 44 19058 60 15104 - 
17.151.236.24 90 28 432 40 20 386 50 = 8 046 - 
216.58.196.109 80 35144 36 «17770 44 17374 - 
216.58.196,98 72 28854 32 16.536 40 12318 - L 
17.167,194.236 60 14250 28 = 10820 323.430 - “! 


a 





Name resolution O Limit to display filter 


Endpoints dialog—IPv4 tab 


To create a display filter through the Endpoints 
window, right-click on the row with the most packets 
transferred and choose Selected under Apply as Filter, 
as shown in the following screenshot: 
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You see a display filter for the same in the Display 
Filter dialog above the List pane, like the one shown 
here: 





Filter: |ip.addr==172.20.10,7 _+ | Expression... Clear | Save 


This facilitates us to quickly analyze traffic for a certain 
endpoint and hence increases the speed of analysis for 
users. Once you click on Clear, you will be presented 
with the same Endpoints dialog. At the bottom of the 
window, you will see two checkboxes and a few 
buttons. The purpose of each is listed below: 


e Name Resolution: Resolves the name of each 
of the Ethernet 
addresses listed in the Ethernet tab. But in some 
scenarios, it might 
affect the performance of the application 
adversely, for example, 
when trying to resolve the unique IP addresses 
from a huge capture file. 


e Limit to display filter: Limits the results of the 
Endpoint window on the basis of a display filter 
that is applied through the Wireshark main 
window. 


e Copy: Copies the content of the current 
Endpoints window tab in a 
CSV format (comma-separated values). 





Follow TCP Streams 


Wireshark provides the feature of reassembling a 


stream of plain text protocol packets into a human- 
readable format: 


eee \ Follow TCP Stream (tcp.stream eq 8) 
Stream Content 


GET /GIAG2.crt HTTP/1.1 4 
Host: pki.google.com C 
Accept: */* 

Accept-Language: en-us 

Connection: keep-alive 

Accept-Encoding: gzip, deflate 

User-Agent: ocspd/1.0.3 


HTTP/1.1 200 OK 

Vary: Accept-Encoding 

Content-Type: application/x-x509-ca-cert 
Last-Modified: Fri, 08 May 2015 18:51:37 GMT 
Date: Sat, 25 Jul 2015 11:26:50 GMT 
Expires: Sat, 25 Jul 2015 12:26:50 GMT 
X-Content-Type-Options: nosniff 

Server: sffe 

X-XSS-Protection: 1; mode=block 

Age: 117 

Cache-Control: public, max-age=3600 
Alternate-Protocol: 80:quic, p=0 
Accept-Ranges: none 

Transfer-Encoding: chunked 





“. Find | fal Save As | c=Print lo ASCIl| O EBCDIC OHexDump OCArrays ® Raw 
Help Filter Out This Stream | XM Close 


Follow TCP Stream window 


For instance, assembling an HTTP session will display 
the GET requests sent from the client and the 
responses received from the server. There is specific 
color coding that is followed by the request and 
response messages shown in the Follow TCP Stream 


dialog. Client requests are shown in red, and any text 
in blue denotes the response received from the server. 
If the protocol is HTTP FTP Telnet, and so on, then the 
conversation will be shown in plain text; if a secure 
version of the application layer protocol is used, then 
some content of the request and response messages 
will be encrypted. 


At the bottom of the Follow TCP stream dialog, a drop- 
down menu is present from where content in the 
Follow TCP stream window can be filtered to view only 
content pertaining to either side of the communication. 
Also, instead of just viewing the data in RAW format, 
you can choose between ASCII, EBCDIC, Hex dump, 
and C arrays format, as desired. 


To view the TCP stream, follow these steps: 


1. Open the capture/trace file 

2. Apply the Display filter if required 

3. Select any packet from the List pane 

4. Right-click on the selected packet and click on 
Follow TCP Stream 


Command line-fu 


With the default installation of Wireshark, a command- 
line version of protocol analyser called Tshark also 
gets installed. There are a good number of CUI-based 
sniffing tools available, including Capinfos, Dumpcap, 
Editcap, Mergecap, Rawshark, Reordercap, 
Text2pcap, and Tshark. 


The most common and widely used command-line tool 
for protocol analysis purposes is Tshark, which can 
capture live traffic and analyze saved capture files. 
Tshark uses the pcap library to capture and translate the 
packets. Just like Wireshark's filtering option are 
available in Tshark too. Applications like Tshark prove 
themselves worthy, with benefits such as low memory 
requirement, easy installation, and simple command 
sets to run the sniffer. 


Let's consider a scenario to understand the usage and 
advantages of command-line sniffers. Say, for instance, 
we have an Apache web server and an FTP server 
running on a Windows box located at IP 172.16.136.128, and 
a Macintosh client running at 172.16.136.1: 


2 ee el 


PC 1: Macintosh (172.16.136.1} PC 2: Windows AP 
(172.16.136.128) 


We will start with the basics and eventually move 
toward the usage of advanced features such as filters 
and usage of a few of the available statistics options. 


Let's try the tool with usage of different features it 
facilitates: 


e The first thing to confirm is how many interfaces 
are available for capturing packets. Use the 
following command to check tshark -p: 


Anonymous:Desktop NotFound$ tshark -—D 
» en® (Ethernet) 

. fw® (FireWire) 

+» bridge@® (Thunderbolt Bridge) 

utune® 

. pktape 

» eni (Wi-Fi) 

» en2 (Thunderbolt 1) 

- lo®@ (Loopback) 


1 
2 
3 
4. 
5 
6 
7 
8 





Interfaces available 


e If no interface is specified for capturing network 
traffic, tshark will choose the first interface from 
the list. Interfaces can be chosen by their names 
and by the sequence number they appear in. 


e For our scenario, we will be using pktapo that will 
listen to the traffic between the client and the 
server. The command to initiate the capture 
PLOCESS iS tshark -i pktapo: 


Anonymous:Desktop NotFound$ tshark —i pktape@ 
Capturing on ‘pktape' 





e In order to generate some traffic between the 
client and the server, I have executed the 
command-line utility cun from the client to visit 
the web page at IP 172.16.136.128: 


Anonymous :Desktop NotFound$ curl http://172.16.136.128 





e Asaresult of the preceding command, we will 
see some activity on the Tshark console: 


Anonymous:Desktop NotFound$ tshark -i pktap@ 
Capturing on ‘pktape' 


1 


©.000000 172.16.136.1 -> 172.16.136.128 TCP 64 51816-80 [SYN] Seq=@ Win=65535 Len=® MSS=1460 
~745883619.604183 172.16.136.128 —> 172.16.136.1 TCP 64 80+-51816 [SYN, ACK] Seq=@ Ack=1 Win=64240 
~733373297.062554 172.16.136.1 —> 172.16.136.128 TCP 52 51816-80 [ACK] Seq=1 Ack=1 Wine131744 Len 
~1830766245.431098 172.16.136.1 -—> 172.16.136.128 HTTP 130 GET / HTTP/1.1 
~1830766245.129806 172.16.136.1 -> 172.16.136.128 HTTP 13@ [TCP Retransmission] GET / HTTP/1.1 
-1664501840.066843 172.16.136.128 —> 172.16.136.1 TCP 52 8@+-51816 [ACK] Seq=1 Ack=79 Win=64162 Le 
-392509417.396438 172.16.136.128 -> 172.16.136.1 TCP 52 [TCP Dup ACK 681] 8@-51816 [ACK] Seqel Ac 
~2027256734.439159 172.16.136.128 -> 172.16.136.1 HTTP 345 HTTP/1.1 302 Found 
~179068134.420122 172.16.136.1 -> 172.16.136.128 TCP 52 51816~80 [ACK] Seq=79 Ack=294 Win=131456 
~2067155579.763355 172.16.136.1 —> 172.16.136.128 TCP 52 51616~-80 [FIN, ACK] Seq=79 Ack=294 Win=1 
-1830766248.828112 172.16.136.128 -> 172.16.136.1 TCP 52 8@+-51816 [ACK] Seqe294 Ack=80 Wine64162 
—392509283.614178 172.16.136.1 —> 172.16.136.128 TCP 52 [TCP Dup ACK 10#1] 51816-80 [ACK] Seq=80 
~1830766248.686849 172.16.136.128 —> 172.16.136.1 TCP 52 8@-51816 [FIN, ACK] Seq=294 Ack=8@ Win=6 
~392569681.317465 172.16.136.1 —> 172.16.136.128 TCP 52 51816-8080 [ACK] Seq=8® Ack=295 Win=131456 





Packets captured at pktapO 
If you want to stop the capture process at any point, press 
Ctrl + C. 


e If you wish to save captured network packets to 
a file, specify the -w switch, as follows: 


Anonymous:Desktop NotFound$ tshark -i pktap® -w http.txt 
Capturing on ‘pktape' 
11 





e As a result of the preceding command, the raw 
network data will be stored in a text file 


named nttp.txt. Following is the content saved in 
the text file: 


Anonymous:Desktop NotFound$ cat http.txt 


2M<+?7277272772.Mac OS X 10.10.3, build 140136 (Darwin 14.3.0)4Dumpcap 


D136 (Darwin 14.3.0)**??7@QE@f7@@k77777771P77F777777 
222x* *dA???_@QE@7@7}, 277727P7L 705777772077 
@0q7777771P77F77057 

222xT?724227927E2 727@QGH7777777LP27F 7705 7h 

?7??xGET / HTTP/1.1 

User-Agent: curl/7.37.1 

Host: 172.16.136.128 

Accept: */* 





Raw data stored in the text file 


e To save the captured data in a readable form, 
just use the redirection operator ">>" to a file: 


Anonymous:Desktop NotFound$ tshark -i pktap® 
Capturing on ‘pktape' 

@.000000 172.16.136.1 -> 172.16.136.128 TCP 64 51816-80 [SYN] Seq=@ Win=65535 Len=® MSS=1460 
-745883619.604183 172.16.136.128 —> 172.16.136.1 TCP 64 86+-51816 [SYN, ACK] Seq=@ Ack=1 Win=64240 
~733373297.062554 172.16.136.1 -> 172.16.136.128 TCP 52 51616-80 [ACK] Seqel Ack#1 Wine131744 Len 
~1830766245.431098 172.16.136.1 —> 172.16.136.128 HTTP 136 GET / HTTP/1.1 
~1830766245.129806 172.16.136.1 -—> 172.16.136.128 HTTP 13@ [TCP Retransmission] GET / HTTP/1.1 
-1664501840.066843 172.16.136.128 —> 172.16.136.1 TCP 52 8@+-51816 [ACK] Seq=1 Ack=79 Win=64162 Le 
=392509417.396438 172.16.136.128 —> 172.16.136.1 TCP 52 [TCP Dup ACK 6#1] 8@+51816 [ACK] Seqe1 Ac 
~2027256734.439159 172.16.136.128 -> 172.16.136.1 HTTP 345 HTTP/1.1 302 Found 
~179068134.420122 172.16.136.1 —> 172.16.136.128 TCP 52 51816-80 [ACK] Seq=79 Ack=294 Win=131456 
~2067155579.763355 172.16.136.1 —> 172.16.136.128 TCP 52 51616-80 [FIN, ACK] Seq=79 Ack=294 Win=1 
~1830766248.628112 172.16.136.128 -—> 172.16.136.1 TCP 52 8@-51816 [ACK] Seqe294 Acke8@ Win64162 
~392509283.614178 172.16.136.1 -—> 172.16.136.128 TCP 52 [TCP Dup ACK 10#1) 51816-8@ [ACK] Seq=80 
~1830766248.686849 172.16.136.128 -—> 172.16.136.1 TCP 52 8@-51816 [FIN, ACK] Seq=294 Ack=8@ Win=6 
~392569681.317465 172.16.136.1 -> 172.16.136.128 TCP 52 51616-80 [ACK] Seq=8@ Ack=295 Win=131456 





As a result of issuing the preceding command, packets 
are captured and redirected to the text file nttp2. txt. 
Following is the content saved in the text file, that lists 
the packets captured between the two hosts 172.16.136.128 
and 172.16.136.1 OVer port so: 


Anonymous :Desktop NotPound$ cat http2, txt 
1 0.000000 172.16,136.1 => 172.16.136,128 TCP 64 5182180 [SYN] Seq=@ Win=65535 Len=@ MSS=1460 W5=32 
2 1830767469. 040043 172.16,136,128 -> 172.16.136.1 TCP 64 80451821 [SYN, ACK] Seq=@ Ack=l Win=§4240 
3 =1830767469.040009 172.16,136.1 =» 172.16.136,128 TCP 52 51821480 [ACK] Seqel Ackel Winel31744 Lenad 
4 =2016704535, 647514 172.16.136.1 => 172.16.136,128 HTTP 130 GET / HTTP/1.1 
5 2027256734. 427691 172.16.136,128 -> 172.16.136.1 HITP 345 HITP/1.1 302 Found 


6 =1830767469.037172 172.16.136.1 => 172.16.136.128 TCP 52 51821480 [ACK] Sequ79 Acke294 Winel31456 Le 
7 =1830767469.037084 172.16.136.1 => 172.16.136.128 TCP 52 51821480 (FIN, ACK) Seqe79 Acke294 Win=1314 
@ 1935145592, 773838 172,16.136.128 -> 172,16.136.1 TCP 52 G0-51821 [ACK] Seqe204 Ack=BO Win=64162 Le 
9 =1830767469.036949 172.16.136.1 => 172.16. 136.128 TCP 52 [TCP up ACK 7#1) 51821-80 [ACK] SeqeBb Ach 
10 =1935145592, 773838 172.16. 136,128 => 172.16.136.1 TCP 52 80451821 (FIN, ACK) Seqe294 Acknld Winné4é 
11 -1830767469,036570 172.16.136.1 => 172,16.136,128 TCP 52 51821480 [ACK] Seq=B) Ack=295 Win=131456 Le 





We just learnt the two different ways to save network 
packets to a file. 


e Tshark facilitates three types of filtering options: 
Capture, Display, and Read. We have discussed 
the Capture and Display filters in earlier 
chapters, so let's discuss the read filter. The 
read filter is able to filter traffic from live as well 
as save captured files. Through read filters a 
particular set of packets can be decoded or 
written to a file. 


e Using the Read filter is a processor-intensive 
task, and issues like packet loss could be 
observed, and capture filters are preferred over 
read filters. For the capture filter the -+ switch is 
used; -r is used for the read filter; and -y is used 
for the display filter. Let's learn the usage of the 
capture filter using -+ switch: 


Usage of a switch is case-sensitive. 


Capturing on ‘pktape' 
@.000000 172.16.136.1 -—> 172.16.136.128 TCP 64 51852+20 [SYN] Seq=@ W 


~565845755.905104 172.16.136.128 —> 172.16.136.1 FTP-DATA 94 FTP Data: 
@.330476 172.16.136.1 -—> 172.16.136.128 TCP 52 51852~20 [ACK] Seq=1 Aq 

—1438260168.702253 172.16.136.128 —> 172.16.136.1 FTP-DATA 97 FTP Data: 

~776735948.749363 172.16.136.1 —> 172.16.136.128 TCP 52 51852~28 [ACK] § 





e Use double quotes around the filter expression, 
if the desired expression has space character 
like shown in preceding screenshot for example 


a port<space>20- : 


e Now, let's learn the usage of the display filter 
over a previously saved capture file nttp.pcap, and 
filter all HTTP packets originating from the web 
Server at IP 172.16.136.128: 


Anonymous:Desktop NotFound$ tshark -r http.pcap -Y “ip.srce=172.16.136.128 and http” 
—2027256734.408549 172.16.136.128 -> 172.16.136.1 HTTP 345 HTTP/1.1 302 Found 
~2027256734.408549 172.16.136.128 —> 172.16.136.1 HTTP 345 HTTP/1.1 302 Found 
-1899318681.597223 172.16.136.128 239.255.255.250 SSOP 161 M-SEARCH * HTTP/1. 
~1899316681.597223 172.16.136.128 239.255.255.250 SSOP 161 M—-SEARCH « HTTP/1. 


~1899318681.597223 172.16.136.128 239.255.255.25@ SSOP 161 M-SEARCH * HTTP/1. 

—1899318681.597223 172.16.136.128 239.255.255.258 SSOP 161 M-SEARCH + HTTP/1. 

~2027256734.408549 172.16.136.128 172.16.136.1 HTTP 345 HTTP/1.1 302 Found 
619 —2027256734.408549 172.16.136.128 172.16.136.1 HTTP 345 HTTP/1.1 302 Found 
653 -2027256734.406549 172.16.136.128 —> 172.16.136.1 HTTP 345 HTTP/1.1 302 Found 
1925 ~1830772787.988137 172.16.136.128 —> 172.16.136.1 HTTP 345 HTTP/1.1 302 Found 


Tshark display filter 





¢ In order to collect the HTTP protocol, only 
statistics from the nttp.pcap file use the 


Command tshark -r <file-name> -q -z <expression>: 


Anonysous: Desktop NotFounds tshark -r http.pcap -q -z http, tree 


HTTP/Packet Counter: 
Topic / Item Average Min val Max vel Rate (ms) Percent 
Totel HTTP Packets 1008 
HTTP Request Peckets 64.71% 
GET 
SEARCH 
HTTP Response Packets 
Sux: Redirection 
302 Found 
777: broken 
xxl Server Error 
xxi Client Error 
xx: Success 
: Informational 
HTTP Packets 


eeeeeeooooes 





e The -q switch keeps it silent over the standard 
output (this is generally used while working with 
statistics in Wireshark) and the -z switch is used 
for activating various Statistics options. Both 
switches are often used in conjunction. 


e If you want to check how many hosts were 
observed while capturing the network traffic, 


use the following command: 

Anonymous:Desktop NotFound$ tshark <r http.pcap -q -z hosts 
# TShark hosts output 

# 


# Host data gathered from http.pcap 


172.16,158.1 Anonymous. Local 
172.16.136.1 Anonymous. local 





Tshark is a powerful yet simple command-line sniffer 
which is similar to tcpdump. It enables capturing of 
network packets with ease and less 
configuration/installation required. 


Summary 


The Conversations window lists information pertaining 
to communication between two hosts. 


The Endpoints dialog lists details pertaining to the 
devices connected to the network. 


Wireshark Summary is an informational feature, which 
offers a granular form of data, filters, and the trace file. 


The Protocol Hierarchy window lists information in a 
tabular format pertaining to distribution of protocols 
used by the network endpoints. 


Use the Follow TCP Stream option in Wireshark to 
read the plain text data from captured packets. There 
are different viewing options available such as ASCII, 
and Hex. 


A command-line tool gets installed when you install 
Wireshark. The most common tool used is Tshark, 
which works in a similar way to Wireshark and tcpdump. It 
uses the pcap library that is used by other major 
protocol analyzers. 


With Tshark, you can listen to live networks or work 
with an already saved capture file. 


Other Books You May 
Enjoy 


If you enjoyed this book, you may be interested in 
these other books by Packt: 


Wireshark 2 


Packt» 





Mastering Wireshark 2 
Andrew Crouthamel 


ISBN: 978-1-78862-652-1 
e Understand what network and protocol analysis 
is and how it can help you 


e Use Wireshark to capture packets in your 
network 


e Filter captured traffic to only show what you 
need 


e Explore useful statistic displays to make it easier 
to diagnose issues 


e Customize Wireshark to your own specifications 


e Analyze common network and network 
application protocols 


Network Analysis 
Using Wireshark 2 


(Gere) <olere). 


Packt> 





Network Analysis using Wireshark 2 Cookbook - 
Second Edition 

Nagendra Kumar Nainar, Yogesh Ramdoss, Yoram 
Orzach 


ISBN: 978-1-78646-167-4 
e Configure Wireshark 2 for effective network 
analysis and troubleshooting 
e Set up various display and capture filters 


e Understand networking layers, including IPv4 
and IPv6 analysis 


e Explore performance issues in TCP/IP 


e Get to know about Wi-Fi testing and how to 
resolve problems related to wireless LANs 


e Get information about network phenomena, 
events, and errors 


e Locate faults in detecting security failures and 
breaches in networks 


Leave a review - let 
other readers know 
what you think 


Please share your thoughts on this book with others by 
leaving a review on the site that you bought it from. If 
you purchased the book from Amazon, please leave us 
an honest review on this book's Amazon page. This is 
vital so that other potential readers can see and use 
your unbiased opinion to make purchasing decisions, 
we can understand what our customers think about 
our products, and our authors can see your feedback 
on the title that they have worked with Packt to create. 
It will only take a few minutes of your time, but is 
valuable to other potential customers, our authors, and 
Packt. Thank you! 


